logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Britton, David" <...@hp.com>
Subject RE: Thread Specific Appender
Date Thu, 10 Apr 2008 15:39:52 GMT
Paul Smith wrote:
> I actually don't need it.. Someone else needed it and I just proposed
> an idea.

I see -- yes, sorry about that. :)

Here is the solution that I had come up with:

I currently have a small job-scheduling framework that launches jobs in threads.  We are interested
in each thread creating a thread-specific appender so that log messages that integrate into
the log4j framework can be copied into that thread-specific log file.  We also want this to
be configurable to a certain extent in the log4j.xml file.

These jobs are created dynamically, and there will be many of them.

I researched MDC, and found that it works very nicely for adding thread-specific meta-data
into log message, so I thought that it would work nicely to make use of that notion to allow
easy run-time division of the log files.

Also, in previous projects I have often thought it would be nice to have a file appender that
can respond to run-time changes in the application (not just thread boundaries, but any run-time
change).  This doesn't make sense in applications that need only 2 or 3 static log files,
but when the app has a whole repository of log files, I have usually had to resort to a very
complicated system of creating new loggers/appenders, binding them, unbinding them, etc, all
through code, which then becomes had for others to understand, and impossible to change without

So, to address both those problems, I created a new class:


This class will allow you to specify patterns in the log file name that will be interpretted
at log-time (The same patterns in PatternFormat).  So, you can use the MDC + this to specify
new log files.  This still doesn't solve the problem entirely since I don't want this appender
to be active unless I'm in one of contexts where I'm needing this dynamic log file.  To that
end, I have also written a simple filter:


This filter will allow you to filter on MDC content (only strings supported for now).  So,
the appender can be easily skipped if the application is not ready for that class of appenders.
 This is similar to turning the appender off programatically, but it benefits from the thread-specifc
nature of MDC, and is intuative in the code & XML config.

My only concerns at this point are around performance issues.  I think there are things I
can do to speed up the performance, but I'm not sure how to judge an increase in performance,
etc.  Is there a suite of tests that do that already do performance measures in log4j?

David Britton <dpb@hp.com>

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message