[slf4j-user] nlog4j problems under load

Ceki Gulcu listid at qos.ch
Mon Jul 2 20:45:35 CEST 2007


Norval,

It looks like you are sharing layout between various appender instances. Layouts 
are not meant to be shared. There should be a distinct layout instance for each 
appender. By the way, the usage problem is not NLOG4J specific, it would also 
occur under log4j or logback for that matter.

HTH,

Norval Hope wrote:
> Hi,
>  
> I am in the final stages of preparing a release that builds on top of 
> ApacheDS, and consequently must use an slf4j compliant logging library 
> so I used nlog4j 1.2.25 (as AD does).
>  
> I have a requirement to have separate appenders created dynamically at 
> runtime and adopted the approach shown in the small attached test/config 
> files, which was:
>   1. to have a template appender copied every time a new appender is 
> required
>   2. have a stub logger used only so that I can discover the template 
> appender when I need it (as the template appender is in this loggers 
> appender list in the .properties config file)
>   3. to dynamically create a logger intended to send output to the 
> dynamically created appender only (additivity is false and no other 
> logger knows about each particular appender instance).
>  
> This all works fine under normal load, but noted some problems under 
> heavy logging load so I wrote the stand alone test to investigate.
>  
> Running the test with 2 threads and no delay ("java 
> nlog4jtest.NLog4jTest 2 0") causing problems immediately on a dual core 
> laptop running windows xp:
>   1. log messages from one logger appear against appenders to which they 
> are not linked
>   2. partial log messages are evident, where headers are missing etc.
> Using a delay of 5 milliseconds improved the situation but still both 
> problems were evident.
>  
> On a single cpu windows box running xp, "java nlog4jtest.NLog4jTest 10 
> 0" also evidenced both problems too.
>  
> I know I'm making use of a bespoke approach here, so I'm hoping I'm 
> doing something wrong in my implementation or breaking some contract I'm 
> not aware of. I basically can't ship with logging in this state and 
> can't migrate to logback due to LGPL license, which is a problem for the 
> ApacheDS project too.
>  
> Any expert advice about alternative implementation approaches or how to 
> best approach debugging would be greatly appreciated.
>  
> Many Thanks,
> Norval

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch



More information about the slf4j-user mailing list