logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Log files rename failed
Date Wed, 22 Jan 2014 06:16:57 GMT
Are we looking at the same code?

First, File.renameTo doesn’t throw exceptions when the rename fails. It returns false. 
In Java 7 we can use Files.move().  We should update the code to use that if running on Java

Second, if renameTo fails we try to copy the file and then delete it.  If those throw an exception
then the exception is logged to the status logger.  The only operations that don’t log the
exception is the call to mkdirs and the call to delete when the file is empty, neither of
which really get much extra information by logging the exception.

To diagnose the problem I would suggest running with status=debug on the configuration element.
 Since this is windows I suspect the file is probably being read by someone or something at
the time of the rollover and so Windows won’t allow the file to be renamed or deleted. I
don’t know of a good workaround for this (other than running on a different OS).  In doing
google searches I am also seeing mention of some issues where File.delete() fails even though
the FileOutputStream was closed because the Object hasn’t been garbage collected (again,
this only seems to be a problem on Windows).  However, this doesn’t really explain why the
next rollover also fails.


On Jan 21, 2014, at 7:44 PM, Gary Gregory <garydgregory@gmail.com> wrote:

> On Tue, Jan 21, 2014 at 9:42 PM, Steven Yang <kenshin520@gmail.com> wrote:
>> I have observed a file-rename issue while using rolling appender.
>> I am using log4j2-beta9.
>> This main reason I switched to log4j2 is because the same problem occurs in
>> log4j 1.x and the only way to fix it is to modify the source which is
>> something we dont want to do unless it's the last option, while not
>> modifying any of our current source code.
>> Therefore addition to the log4j2 core jars we also have log4j-1.2-api.jar
>> have
>> to replace the original log4j we also have binding from commons-logging to
>> log4j2.
>> The environment is running on a VM with Windows Server 2008 running
>> Websphere 8.
>> My configuration looks like
>> <RollingFile name="wmsRollingFile" fileName="${fileroot}/wms/wms.log"
>> filePattern="${fileroot}/wms/wms-%d{MM-dd-yyyy}-%i.log.gz">
>>      <PatternLayout pattern="%d [%t] %C %l %-5p %c - %m%n"/>
>>      <Policies>
>>        <SizeBasedTriggeringPolicy size="10 MB"/>
>>        <TimeBasedTriggeringPolicy />
>>      </Policies>
>> </RollingFile>
>> <logger name="org.springframework" level="debug" additivity="false">
>>        <appender-ref ref="wmsRollingFile"/>
>>    </logger>
>>    <logger name="org.apache.http" level="debug" additivity="false">
>>        <appender-ref ref="wmsRollingFile"/>
>>    </logger>
>>    <root level="info">
>>      <!-- <appender-ref ref="STDOUT"/> -->
>>      <appender-ref ref="wmsRollingFile"/>
>>    </root>
>> I also have other appenders with similar setting but just logs to different
>> files. (they are not used/written much but do have same problem"
>> As you can see, I have set the log policy to size 10MB and by time.
>> What I have observed is that when it runs correctly, log files get gz at
>> 10MB and restarts a new one and everything runs correctly. However, as soon
>> as one roll failed, the log size just keep increasing. When it comes to the
>> daily rolling part, a new file with correct timestamp is created. However
>> the original log file does not get cleaned up and the new logs just kept
>> append to the old log file. This causes log file size increase each day
>> with duplicated entries.
>> When I check the WAS error log I see something like the following:
>> "log4j:ERROR Failed to rename [D:/WMS_AP/logs/TWI900WMAPT01/wms/wms.log] to
>> [D:/WMS_AP/logs/TWI900WMAPT01/wms/wms.log_20140120.txt]."
>> Is there a way to see more detailed error message from log4j?
>> Or what could possibly be the problem? What should I investigate?
> Before I ask Steven to try the trunk code or the latest SNAPSHOT:
> @devs: In
> org.apache.logging.log4j.core.appender.rolling.helper.FileRenameAction, I
> see that we log errors when catching exceptions BUT we do not log the
> exception object itself which means that we are missing the opportunity to
> log any nested exceptions, which in this case could be helpful.
> Is this by design? If not, I propose we add exception objects to these
> error calls.
> Gary
>> Thanks
> -- 
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message