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 2007/10/29 20:49:13 UTC
DO NOT REPLY [Bug 43728] - Log file loss when specified file is locked
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=43728>.
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=43728
------- Additional Comments From mgeiser@mgeiser.net 2007-10-29 12:49 -------
Using a clustered WebLogic server with two managed server, we misconfigured
the DailyRollingFileAppender so that both managed servers to use the same log
file.
Each managed server runs in it's own JVM and the two JVMS cannot have an
exclusive lock on the same file (duh!)
I noticed that the log files for previous intervals frequently contained data
from the wrong time interval, some data was entirely missing and that you have
to look in the current log as well as the log for the previous interval to
ensure you get all the logged information.
It appeared one of the JVMs wrote to the previous interval log and over-wrote
the logs from that interval.
To conclusively demonstrate this was the case, I left both Log4j config files
specify the same log file but added the sting "MS1" and "MS2" to the
ConversionPattern parameter for each log file so that it was apparent which
managed server was writing to which log file.
I saw when both Managed Servers try to log to the same log, one managed server
writes to the specified file (the Managed Server that does get the lock
varies) and the other managed server writes to the previous interval�s log
file. Since the appenders also do not specify to append to (but instead
overwrite) files, the previous interval�s log file is overwritten with new
data. This also confirmed that a managed server always wrote to the same log
file instead of each managed server opportunistically writing to any unlocked
log file.
We can see demonstrated this below. The first few bytes of the first lines of
the files are associated with the log file name.
Prior to 10:00am, only one managed server (MS1) had any activity to log and it
logged to the docmgt.log file.
At 10:00am, I ran a test were a client ran 10 treads calling an EJB via RMI.
The 10 calls were balanced by WebLogic across the two managed servers in the
domain. When this test ran and both Managed Servers were being used, the log
data from MS1 that was in the docmgt.log file was now located in
docmgt.log.2007-10-28-PM (the docmgt.log file at 9:58 was renamed) and the
data from MS2 was logged to the docmgt.log file. The data that was in
docmgt.log.2007-10-28-PM prior to 10:00am was over-written and lost.
at 9:58 am
docmgt.log |MS1|20071029||08:56:05,850||
docmgt.log.2007-10-28-PM |MS2|20071028||21:20:08,318||
docmgt.log.2007-10-27-PM |MS1|20071028||21:19:41,689||
docmgt.log.2007-10-27-AM |MS2|20071027||19:55:26,386||
docmgt.log.2007-10-26-PM |MS1|20071026||12:59:47,760||
docmgt.log.2007-10-26-AM |MS1|20071027||00:46:54,637||
docmgt.log.2007-10-25-PM |MS2|20071026||09:15:08,077||
at 10:01
docmgt.log |MS2|20071029||10:00:22,993||
docmgt.log.2007-10-28-PM |MS1|20071029||08:56:05,850||
docmgt.log.2007-10-27-PM |MS1|20071028||21:19:41,689||
docmgt.log.2007-10-27-AM |MS2|20071027||19:55:26,386||
docmgt.log.2007-10-26-PM |MS1|20071026||12:59:47,760||
docmgt.log.2007-10-26-AM |MS1|20071027||00:46:54,637||
docmgt.log.2007-10-25-PM |MS2|20071026||09:15:08,077||
Although we could specify the append parameter be true, overwritting the file
in this case is clearly a bug. It is important to perform the log, but there
is not alert that there is a file contention and it would be infinately
preferable that the previous interval log NOT be overwritten. add a short
random sting or time stamp to the log file name specified in the appender if
nothing else.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org