logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: DO NOT REPLY [Bug 31458] New: - DailyRollingFileAppender fails with mult load-balancing JVMs under WAS
Date Fri, 01 Oct 2004 22:39:53 GMT
There is no need to develop your own multicast-based logging framework - log4j 1.3 includes
support for transmission and reception of multicast-based logging events.
Here's how:
- Send events using a multicastappender.  
- Set up a socketserver configured with a multicastreceiver as well as a fileappender.
Events received by multicastreceiver are automatically handed to the fileappender.
Here is a link to the multicastappender/receiver sources:

	-----Original Message----- 
	From: Asgeir Nilsen [mailto:Asgeir.Nilsen@telenor.com] 
	Sent: Fri 10/1/2004 11:36 AM 
	To: Log4J Developers List 
	Subject: Re: DO NOT REPLY [Bug 31458] New: - DailyRollingFileAppender fails with mult load-balancing
JVMs under WAS

	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
	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

View raw message