David J. M. Karlsen wrote:
[EMAIL PROTECTED] wrote:
Regarding Bugzilla Bug 24107 "DailyRollingFileAppender sharing target File in multiple EARS"
We are encountering this in a WebSphere clustered environment so that while we DO have 4 separate JVMs, they are cloned under WAS, which uses the multiple JVMs for load balancing. This bug would indicate that if you are running in a load balanced environment with multiple servers, then the DailyRollingFileAppender will not work.
Thanks for your consideration in re-opening bug 24107 or looking into this variation of that bug.
are you really sure?
I think you have a condition where the different processes try to write the same file. That issue is general and not related to Log4j.
use some system property to distinguish the instances in the config file and let them write to different files ....=/var/log/{some.property}/logfile
OR
use an common socket appender which writes to the file
OR
use syslog appender which can be used by all intances and collected on a common syslogserver.
The problem we've experienced in this context, is that the rolling over is error-prone, and actually does not happen sometimes.
We have experienced that different enterprise applications (.ear files) write to the files logfile.log, logfile.log.YYYY-MM-D1, and logfile.log.YYYY.MM.D2
Look at this example:
57852 sep 29 20:50 monitoring.log2004-09-28 105702 sep 30 14:40 monitoring.log2004-09-29 3665 okt 1 15:10 monitoring.log 69394 okt 1 19:20 monitoring.log2004-09-30
As you can see, the rolled-over file from yesterday is actually the most recent one written to. Also note that the file for Sep 29th was written to some 14 /hours/ into Sep 30th! It is even worse for the file from Sep 28th ..
The reason for this is probably that separate log4j Logger instances are created within each enterprise application, and that these instances are not coordinated.
We are currently in the process of implementing a logging framework based on UDP multicast, where each application drops it's LogEvents to a multicast group address, and one receiver on a single logging server receives these and writes them to file and handles the rolling.
If we later want to create redundant logging, we could just add a second receiving server to the multicast group.
A similar multicast => socket bridging server is used to feed XMLLayout'ed events into Chainsaw for real-time monitoring outside the firewalled production environment.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
