logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Yang <kenshin...@gmail.com>
Subject Re: Log files rename failed
Date Wed, 22 Jan 2014 09:33:19 GMT
The environment is in IBM Java 6 so I suppose File.move() won't help me.
I will try setting status=debug to see.
And while you mention FileOutputStream close problem, we do have a function
to allow user to download current log, which might be the problem. I will
make sure whether this is the problem. However, the log continues to not
rollover even after AP restart.

Just wondering, if opening the file indeed is causing the problem, will
copying the file using File.copy() or IOUtils.copy() then read the copied
file help solving the problem?

Also is it possible for log4j to also write the actual command (copy/move),
if no exception is available, when it fails to rename the file? or is
"rename" is already clear enough?

Thanks


On Wed, Jan 22, 2014 at 2:16 PM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

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

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