You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2004/09/28 22:39:19 UTC
DO NOT REPLY [Bug 31458] New: -
DailyRollingFileAppender fails with mult load-balancing JVMs under WAS
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31458>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31458
DailyRollingFileAppender fails with mult load-balancing JVMs under WAS
Summary: DailyRollingFileAppender fails with mult load-balancing
JVMs under WAS
Product: Log4j
Version: unspecified
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: Normal
Priority: Other
Component: Appender
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: lisa.huber@fmr.com
CC: lisa.huber@fmr.com
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 31458] New: - DailyRollingFileAppender
fails with mult load-balancing JVMs under WAS
Posted by Asgeir Nilsen <As...@telenor.com>.
David J. M. Karlsen wrote:
> bugzilla@apache.org 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 31458] New: - DailyRollingFileAppender
fails with mult load-balancing JVMs under WAS
Posted by "David J. M. Karlsen" <da...@davidkarlsen.com>.
bugzilla@apache.org wrote:
>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
><http://issues.apache.org/bugzilla/show_bug.cgi?id=31458>.
>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
>INSERTED IN THE BUG DATABASE.
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=31458
>
>DailyRollingFileAppender fails with mult load-balancing JVMs under WAS
>
> Summary: DailyRollingFileAppender fails with mult load-balancing
> JVMs under WAS
> Product: Log4j
> Version: unspecified
> Platform: Sun
> OS/Version: Solaris
> Status: NEW
> Severity: Normal
> Priority: Other
> Component: Appender
> AssignedTo: log4j-dev@logging.apache.org
> ReportedBy: lisa.huber@fmr.com
> CC: lisa.huber@fmr.com
>
>
>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.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org