We do have a couple of JVMs running at once, but the java applications write to separate log files; there is no overlap.
As for the rolling file appender, we're using org.apache.log4j.RollingFileAppender with a 10MB rollover size. The log file sizes were 635kB and 6.42MB respectively when we noted the error and had yet to roll over for the first time. (ie. No *.1, *.2, etc. files) > -----Original Message----- > From: Curt Arnold > Sent: Monday, March 15, 2010 11:23 PM > To: BUNBURY Myles > Subject: Re: Truncated XML output in log4j > > XMLLayout does maintain an instance StringBuffer. Would not > do that if we were writing it from scratch, but since it is > internally synchronized, I don't see how you could get just > "tim" instead of "timestamp". > > Any chance that you have multiple JVM's or instances writing > to the same file? That results in unspecified behavior. > There was an reverted of logback's "prudent" mode (see bug > 48704) that has been observed to reduce simultaneous IO > issues, but don't believe that it offers a hard guarantee. > Would need to have a clean-room implementation of "prudent" > mode by someone who had seen neither logback code or my > implementation of PrudentWriter, though the rest of my patch > should be okay. > > If you aren't pointing multiple appenders to the same file, > then could be something in the RFA. You don't mention what > RFA is in use. They are all problematic since rename() is an > inherently risky and platform specific action. I don't > believe that the RFA's can really be fixed, they need to be > superseded by something based on java.nio and that does not > involve renaming. > > Please ask any additional questions on [email protected]. > > > On Mar 15, 2010, at 2:43 PM, BUNBURY Myles wrote: > > > We're making use of log4j v1.2.15 in our application, and one of our > > testers managed to generate the following snippet in his > XML log file: > > > > <log4j:event logger="oam.com.grizzly.mw.backup.G" > > tim<log4j:event > > logger="oam.com.grizzly.mw.backup.G" > timestamp="1267651500011" > > level="WARN" thread="Audit Export Job @ Wed Mar 03 16:25:00 > EST 2010"> > > <log4j:message><![CDATA[Exporting 8 audit files to SFTP target > > 'test'.]]></log4j:message> > > </log4j:event> > > > > > > You'll note that at the end of the first line, the first log event > > appears truncated and a second log event is written in full. > > > > According to the timestamps, around the same time he > generated a smiliar > > snippet in another XML log file being produced by the same process: > > > > <log4j:event logger="system.com.grizzly.mw.synapse.A" > > timestamp="1267648942916" level="ERROR" thread="HttpSer<log4j:event > > logger="system.com.grizzly.mw.synapse.A" > > timestamp="1267651454673" > > level="ERROR" thread="HttpServerWorker-24"> > > <log4j:message><![CDATA[Message rejected: Could not audit > > MyServiceHttpSoap12Endpoint.]]></log4j:message> > > </log4j:event> > > > > Again, you'll note that at the end of the second line, the > first event > > is truncated and the second event gets written in full. > > > > Both files are written out using a rolling file appender > with immediate > > flush turned on. There does not appear to be evidence that the > > application stopped or restarted around the time that this issue > > occurred, as the log messages before and after seem to > indicate normal > > operation. We've been using log4j v1.2.15 for about 2 years > now in both > > development and production environments, and to my > knowledge, we haven't > > seen this issue before or since. I checked the log4j source > code, and > > everything appears properly synchronized & flushed via doAppend(), > > though I'm not very familiar with the log4j code. > > > > I'm curious as to whether you've heard of something like > this before, or > > if you have any ideas/thoughts on the matter. I'm trying to > figure out > > if it's a bug with us, log4j, or something else. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
