Liav Elias | 29 Jul 07:29 2014

RollingFile appender in tomcat 7 with log4j2

Hi,

I am trying to configure RollingFile appender in tomcat 7 with log4j2 with 5 log files.
I am using in the filePattern the ${sys:catalina.base} but in the log I see the error:

ERROR Unable to create directory C:\eclipse\    omcat7\logs

The same happen if I run tomcat from outside the eclipse (path is different but still there is space in the path).
When I use a path which is hardcoded (C:/temp) it works.
I also tried it with catalina.base and I get the same result.
The interesting part is that the first log file (without a number) is created ok under tomcat/logs - which
means it succeeds to map the filename attribute to a real path
Here is the full appender I use:

<RollingFile name="MyLogFile" fileName="${sys:catalina.home}/logs/MyLog.log"
                 filePattern="${sys:catalina.home}/logs/MyLog-%i.log">
      <PatternLayout>
        <Pattern>%d{yyyy-MM-dd HH:mm:ss} [%t] %-5p %c{3} %x - %m%n</Pattern>
      </PatternLayout>
      <Policies>
        <SizeBasedTriggeringPolicy size="10KB"/>
      </Policies>
      <DefaultRolloverStrategy max="5" min="1"/>
</RollingFile>

Thanks for the help,
Liav
This email and any files transmitted with it are confidential material. They are intended solely for the
use of the designated individual or entity to whom they are addressed. If the reader of this message is not
the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of
(Continue reading)

jfloviou | 24 Jul 11:59 2014
Picon

Re: Flume Appender

Hi all,

I'm digging out this Thread from December 2012 as i would like to get fresh
thoughts on these questions.

Before reading the discussion i was also hesitating between a Flume Embedded
Agent or a Flume Appender after and Asynch Appender.
Ralph performance output were very interesting but i feel like he compared
Embedded agent vs Flume Appender without Asynch, with of course great
advantage to the Embedded Agent.

=> Did anybody get to the same question and has fresh thoughts on this topic
?

Best regards

Jeff

--
View this message in context: http://apache-logging.6191.n7.nabble.com/Flume-Appender-tp7089p49684.html
Sent from the Log4j - Users mailing list archive at Nabble.com.
David KOCH | 24 Jul 11:25 2014

Routing based on marker value

Note: Re-send, I got a mail error the first time round. Excuse if
doubly-received.

Hi,

I want to dynamically route to different collections based on the
marker I send with a message in a logger.info(Marker marker, String
string) call. I have no problem doing the equivalent with the thread
context by using ${ctx:key}. However, how can I accomplish the same
based on the marker value, say by using ${marker}?

I wrote a custom marker context which I include below, however it
doesn't really make sense since there are no keys in the marker,
http://pastebin.com/dgEYEfnQ and it does not work either.

Thanks,

/David
Kari Arvonen | 23 Jul 17:36 2014
Picon

How to get Log4j2, Tomcat and Chainsaw work together?

Hello,

Versions:
- Apache Log4j2 2.0 release version
- Apache Tomcat 7.0.54
- Apache Chainsaw 2.1 snapshot (http://people.apache.org/~sdeboy/)
- Oracle Java SE 7 u60 JDK

I have tried to get the XMLLayout to work with Log4j2 assuming it is the
best format for Chainsaw. What is preferred way to do this?

In any case current log4j2.xml placed in one of the Webapps WEB-INF\classes
-directory
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="ALL">
  <Appenders>
    <File name="XmlFile" fileName="logs/0000Atest.log"
immediateFlush="true" append="true">
      <XMLLayout complete="true" charset="UTF-8" compact="false"/>
    </File>
  </Appenders>

  <Loggers>
    <AsyncRoot level="ALL" includeLocation="false">
      <AppenderRef ref="XmlFile"/>
    </AsyncRoot>
  </Loggers>
</Configuration>

Configuration is read properly. Where I have been struggling is which jars
(Continue reading)

David KOCH | 23 Jul 11:40 2014

Typed log messages

Hi,

When I log I do: object_instance -> JSON -> string,
logger.log(<my_json_string_from_object>) in the application only to do the
de-serialisation in each of my custom appenders' append(LogEvent) methods,
followed by appender-specific processing on the de-serialised object.

I would like to know how can I make the serialisation/de-serialisation
procedure less "manual", like I just call logger.log(<my_Object>) and the
LogEvent processed inside the appender's append method contains the object
inside (<my_class>) LogEvent.getMessage().

Thanks,

David
Merten Schumann | 23 Jul 08:32 2014

Logger.setLevel() not supported in 2.0?

Hello,

from "Converting to the Log4j 2 API":
Calls to org.apache.log4j.Logger.setLevel() or similar methods are not supported in the API.
Applications should remove these.

Could imagine the reason, checking getLevel() is final, so it's quick.
But, when you have in your program your good old fixed static Logger log, it's often helpful to toggle its
logger level at runtime, when the method that should be investigated is reached in the code or in the
debugger ... enable DEBUG output and disable it again ...

Am I missing something? Nobody else missing this feature? :-)

Thanx
   Merten

Mariano Gonzalez | 22 Jul 17:18 2014
Picon

Disruptor 3.2.x

Hello,

According to the manual, async loggers require Disruptor 3.0. However, the
3.2.x series of disruptor is available. Have you tried this version? Are
you recommending 3.0 because you found issues with other versions or is it
just in your TODO list to give 3.2 a ride and/or update the manual?

Thanks
VolkerKopetzky | 22 Jul 13:29 2014
Picon

How to set email message header with SMTPAppender and PatternLayout

Hi,

I'm using log4j 1.2.15.

The Appender used for email is:

<appender name="ErrorNotifier" class="org.apache.log4j.net.SMTPAppender">
<param name="Threshold" value="ERROR"/>
<param name="To" value="mail <at> somewhere.com"/>
<param name="From" value="mail <at> somewhere.com"/>
<param name="SMTPHost" value="smtp.mail.com"/>
<param name="BufferSize" value="100"/>
<param name="Subject" value="New Error!"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %d{ISO8601} - %m%n"/>
</layout>
</appender>

This works nicely, yet I would like to add additional email message headers to the message.

Is that possible?

If so, how can I add, for example this header to the email send by the Appender:
X-System-Postid: post12345
X-System-Forumid: forum12345

Many thanx in advance!!

Beste Grüße, kind regards,
Volker Kopetzky
vzk Beratung
Germany & Thailand

phone    +49.6809.2163.30
phone    +66.86.143.77.27
skype    volker.kopetzky
email    vk <at> vzkb.de
wsite    http://www.vzkb.de


Mariano Gonzalez | 21 Jul 16:35 2014
Picon

Re: why is AsyncLoggerContextSelector faster?

Hello Remko,

I'm still a couple of days away from starting my own performance testing.
I'm taking about the difference in the async loggers manual page, more
specifically, the charts that compare sync loggers, to mixed async loggers
against purely async loggers. Since I need to build my own selector, I'm
trying to be clear on how this works internally in order to implement the
less latency possible selector and try to minimize the performance testing
effort.

Thanks for the clarifications!

On Mon, Jul 21, 2014 at 11:22 AM, Remko Popma <remko.popma <at> gmail.com> wrote:

> Hi,
> No that is incorrect.
> If you do not specify AsyncLoggerContextSelector but instead configure with
> <AsyncRoot> and <AsyncLogger> loggers, you _do_ need the disruptor jar on
> the classpath and this does _not_ use AsyncAppender. AsyncAppender is
> completely separate from Async Loggers. Async Loggers (mixed or all async)
> use the disruptor and both need the disruptor jar.
>
> You keep mentioning a performance difference. I was assuming you were
> talking about the performance test results mentioned on the Async Logger
> manual page, but perhaps I was wrong? Are you experiencing a performance
> difference between the two flavors of Async Loggers in your application?
>
>
>
>
> On Mon, Jul 21, 2014 at 11:10 PM, Mariano Gonzalez <
> mariano.l.gonzalez <at> gmail.com> wrote:
>
> > Hello Remko,
> >
> > I think I found the difference. AsyncLoggerContextSelector always returns
> > the same instance of AsyncLoggerContext, which in turns always returns
> > instances of AsyncLogger, which uses disruptor to handle concurrency.
> >
> > However, with any other selector, a standard Logger instance is returned
> > and parallelism is achieved through an AsyncAppender. AsyncAppender use a
> > standard blocking queue instead of using disruptor which explains the
> > performance difference (there's also the fact that
> > AsyncLoggerContextSelector always returns the same context instance and
> > does not spend cycles in the lookup, but I think that is not a
> significant
> > cost once everything was warmed out).
> >
> > http://logging.apache.org/log4j/2.x/manual/async.html says that when
> using
> > mixed type loggers disruptor is needed on the classpath. That seems to be
> > an error. For what I see disruptor is only used when setting all loggers
> > asynchronous.
> >
> > Does this make sense? Anyway around this? Do you have a disruptor
> appender
> > somewhere?
> >
> > Thanks!
> >
> >
> > On Sat, Jul 19, 2014 at 11:55 PM, Remko Popma <remko.popma <at> gmail.com>
> > wrote:
> >
> > > To be honest, I haven't investigated in detail the reason for the
> > > difference in throughput in the performance test.
> > >
> > > Are you measuring the performance of your application container, and
> can
> > > you see an improvement when using Async Loggers?
> > > Do you see a large difference in performance _in your application_
> > between
> > > making all loggers Asynchronous and using mixed synchronous and
> > > Asynchronous loggers?
> > >
> > >
> > > On Sun, Jul 20, 2014 at 7:45 AM, Mariano Gonzalez <
> > > mariano.l.gonzalez <at> gmail.com> wrote:
> > >
> > > > Hello Remko,
> > > >
> > > > Thanks for the insight. I guess my case falls into the wrong end of
> the
> > > > pareto law. My project is a low latency application container, so I
> > need
> > > to
> > > > have:
> > > >
> > > >
> > > >    - low latency
> > > >    - log separation (I actually had to implement my own context
> > selector
> > > >    because my logic is more complicated than the standard
> > > >    ClassLoaderContextSelector case)
> > > >    - I want async loggers by default, but deployed apps need to be
> able
> > > to
> > > >    specify sync loggers
> > > >
> > > >
> > > > Right now I'm kinda meeting those requirements using config file,
> > > AsyncRoot
> > > > and my custom selector, but it'd be really great to achieve a
> > performance
> > > > level like the one that AsyncContextSelector promises.
> > > >
> > > > Is there a way of doing that? For what I see on the code, the
> > > > AsyncLoggerContextSelector's secret sauce is just to always return an
> > > > AsyncLogger on the newInstance() method. Why is that so much faster
> > than
> > > > what ClassLoaderLoggerContextSelector does?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Fri, Jul 18, 2014 at 1:20 PM, Remko Popma <remko.popma <at> gmail.com>
> > > > wrote:
> > > >
> > > > > The Async Loggers created with the context selector have a slightly
> > > > > different mechanism. One of the differences is that LogEvent
> objects
> > > are
> > > > > re-used.
> > > > >
> > > > > However, unless your application is in the low-latency space, I
> would
> > > not
> > > > > worry too much about the performance difference. Both flavors of
> > Async
> > > > > Loggers are much faster than the alternative (Async Appenders).
> > > > >
> > > > > Your point is valid though. I've been thinking about an alternative
> > way
> > > > to
> > > > > configure Async Loggers than via system properties. The work in
> > > progress
> > > > is
> > > > > tracked in Jira ticket LOG4J2-321
> > > > > <https://issues.apache.org/jira/browse/LOG4J2-321>. This is still
> in
> > > the
> > > > > concept phase though. Meanwhile your best option is probably to use
> > > > > ClassLoaderContextSelector and configure with <AsyncRoot> and
> > > > > <AsyncLogger>.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jul 18, 2014 at 10:57 PM, Mariano Gonzalez <
> > > > > mariano.l.gonzalez <at> gmail.com> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > According to the performance charts in the documentation, log4j2
> > has
> > > a
> > > > > > significantly higher throughput when using
> > AsyncLoggerContextSelector
> > > > > than
> > > > > > when using all async loggers with any different selector.
> > > > > >
> > > > > > Why is that? Is it just because the same context is always reused
> > and
> > > > > > there's no lookup like in the ClassLoaderContextSelector case?
> > > > > >
> > > > > > If I need functionality similar to ClassLoaderContextSelector, is
> > > there
> > > > > any
> > > > > > way to get a throughput similar to AsyncLoggerContextSelector?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > >
> > > >
> > >
> >
>
Matt Sicker | 21 Jul 16:30 2014
Picon

Re: why is AsyncLoggerContextSelector faster?

I think he's talking about the ClassLoaderContextSelector which attempts to
find the logger context through several different ways. Using the
sun.reflect.Reflection class to get the caller class itself is one of those
techniques which might slow things down a little.

I actually have a change to LogManager that can help speed up LoggerContext
resolution when you create a Logger using a Class<?> instead of a String.
The ClassLoader of that Class should be passed to the LoggerContextFactory
to help speed up resolution of the appropriate LoggerContext.

On 21 July 2014 09:22, Remko Popma <remko.popma <at> gmail.com> wrote:

> Hi,
> No that is incorrect.
> If you do not specify AsyncLoggerContextSelector but instead configure with
> <AsyncRoot> and <AsyncLogger> loggers, you _do_ need the disruptor jar on
> the classpath and this does _not_ use AsyncAppender. AsyncAppender is
> completely separate from Async Loggers. Async Loggers (mixed or all async)
> use the disruptor and both need the disruptor jar.
>
> You keep mentioning a performance difference. I was assuming you were
> talking about the performance test results mentioned on the Async Logger
> manual page, but perhaps I was wrong? Are you experiencing a performance
> difference between the two flavors of Async Loggers in your application?
>
>
>
>
> On Mon, Jul 21, 2014 at 11:10 PM, Mariano Gonzalez <
> mariano.l.gonzalez <at> gmail.com> wrote:
>
> > Hello Remko,
> >
> > I think I found the difference. AsyncLoggerContextSelector always returns
> > the same instance of AsyncLoggerContext, which in turns always returns
> > instances of AsyncLogger, which uses disruptor to handle concurrency.
> >
> > However, with any other selector, a standard Logger instance is returned
> > and parallelism is achieved through an AsyncAppender. AsyncAppender use a
> > standard blocking queue instead of using disruptor which explains the
> > performance difference (there's also the fact that
> > AsyncLoggerContextSelector always returns the same context instance and
> > does not spend cycles in the lookup, but I think that is not a
> significant
> > cost once everything was warmed out).
> >
> > http://logging.apache.org/log4j/2.x/manual/async.html says that when
> using
> > mixed type loggers disruptor is needed on the classpath. That seems to be
> > an error. For what I see disruptor is only used when setting all loggers
> > asynchronous.
> >
> > Does this make sense? Anyway around this? Do you have a disruptor
> appender
> > somewhere?
> >
> > Thanks!
> >
> >
> > On Sat, Jul 19, 2014 at 11:55 PM, Remko Popma <remko.popma <at> gmail.com>
> > wrote:
> >
> > > To be honest, I haven't investigated in detail the reason for the
> > > difference in throughput in the performance test.
> > >
> > > Are you measuring the performance of your application container, and
> can
> > > you see an improvement when using Async Loggers?
> > > Do you see a large difference in performance _in your application_
> > between
> > > making all loggers Asynchronous and using mixed synchronous and
> > > Asynchronous loggers?
> > >
> > >
> > > On Sun, Jul 20, 2014 at 7:45 AM, Mariano Gonzalez <
> > > mariano.l.gonzalez <at> gmail.com> wrote:
> > >
> > > > Hello Remko,
> > > >
> > > > Thanks for the insight. I guess my case falls into the wrong end of
> the
> > > > pareto law. My project is a low latency application container, so I
> > need
> > > to
> > > > have:
> > > >
> > > >
> > > >    - low latency
> > > >    - log separation (I actually had to implement my own context
> > selector
> > > >    because my logic is more complicated than the standard
> > > >    ClassLoaderContextSelector case)
> > > >    - I want async loggers by default, but deployed apps need to be
> able
> > > to
> > > >    specify sync loggers
> > > >
> > > >
> > > > Right now I'm kinda meeting those requirements using config file,
> > > AsyncRoot
> > > > and my custom selector, but it'd be really great to achieve a
> > performance
> > > > level like the one that AsyncContextSelector promises.
> > > >
> > > > Is there a way of doing that? For what I see on the code, the
> > > > AsyncLoggerContextSelector's secret sauce is just to always return an
> > > > AsyncLogger on the newInstance() method. Why is that so much faster
> > than
> > > > what ClassLoaderLoggerContextSelector does?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Fri, Jul 18, 2014 at 1:20 PM, Remko Popma <remko.popma <at> gmail.com>
> > > > wrote:
> > > >
> > > > > The Async Loggers created with the context selector have a slightly
> > > > > different mechanism. One of the differences is that LogEvent
> objects
> > > are
> > > > > re-used.
> > > > >
> > > > > However, unless your application is in the low-latency space, I
> would
> > > not
> > > > > worry too much about the performance difference. Both flavors of
> > Async
> > > > > Loggers are much faster than the alternative (Async Appenders).
> > > > >
> > > > > Your point is valid though. I've been thinking about an alternative
> > way
> > > > to
> > > > > configure Async Loggers than via system properties. The work in
> > > progress
> > > > is
> > > > > tracked in Jira ticket LOG4J2-321
> > > > > <https://issues.apache.org/jira/browse/LOG4J2-321>. This is still
> in
> > > the
> > > > > concept phase though. Meanwhile your best option is probably to use
> > > > > ClassLoaderContextSelector and configure with <AsyncRoot> and
> > > > > <AsyncLogger>.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jul 18, 2014 at 10:57 PM, Mariano Gonzalez <
> > > > > mariano.l.gonzalez <at> gmail.com> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > According to the performance charts in the documentation, log4j2
> > has
> > > a
> > > > > > significantly higher throughput when using
> > AsyncLoggerContextSelector
> > > > > than
> > > > > > when using all async loggers with any different selector.
> > > > > >
> > > > > > Why is that? Is it just because the same context is always reused
> > and
> > > > > > there's no lookup like in the ClassLoaderContextSelector case?
> > > > > >
> > > > > > If I need functionality similar to ClassLoaderContextSelector, is
> > > there
> > > > > any
> > > > > > way to get a throughput similar to AsyncLoggerContextSelector?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > >
> > > >
> > >
> >
>

--

-- 
Matt Sicker <boards <at> gmail.com>
David KOCH | 20 Jul 20:44 2014

Appenders contains an invalid element or attribute "NoSql"

Hello,

I get this message:

"Appenders contains an invalid element or attribute "NoSql"

at start-up since switching from 2.0-rc1 to 2.0 when attempting to log to
Mongo. My configuration has not changed.

What's the new configuration name of the appender?

Thanks,

/David

Gmane