You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Thomas Tuft Muller <tt...@online.no> on 2001/09/11 12:14:13 UTC
Bug in RollingFileAppender
All,
We have a quite complex application with a lot of threads logging to
different files (appenders). Most of the logging is done via async-appenders
ending up in RollingFileAppenders.
A couple of times a rolling of the main log file cause a deadlock/starvation
of all threads in the application. This is a very serious fault (class A).
Anyone expericenced something similar? Any bugfix?
--
Thomas
*************************************************************************
Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved.
Confidential. No liability whatsoever is accepted for any loss or damage
suffered as a result of accessing this message or any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
RE: Bug in RollingFileAppender
Posted by Thomas Tuft Muller <tt...@online.no>.
| If you have multiple async-appenders going to a single file you
| could be in
| trouble. File writing is all synchronized in the bowels of java.io, but
| renaming depends on your specific implementation of FileSystem.
| It's entirely
| possible that file renaming is not really thread safe.
OK.
| I have a two suggestions:
| Use a different log file for each async-appender: no chance of
| lock collisions
| among appenders
I do this for all appenders except that all categories log to the root
appender which also is async/rollingfile. I've actually not managed to
prevent this since
<Additivity value="false"/>
does not seem to work. All entries are still logged to the root-category.
| Use CompositeRollingAppender with options so that no file rolling
| ever occurs --
| this requires incrementing backup numbers in the opposite
| direction (higher
| numbers are newer files) but you won't deadlock on rollovers.
This is probably a stupid comment, but where is the
CompositeRollingAppender? It's not included in the 1.1.3 distribution.
I suspected the roll-over was buggy. I think I've seen an earlier posting
about this. I think this revolved around which object used as mutex during
roll-over, and might be the cause of my problem.
Thanks for your help.
--
Thomas
*************************************************************************
Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved.
Confidential. No liability whatsoever is accepted for any loss or damage
suffered as a result of accessing this message or any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Bug in RollingFileAppender
Posted by Kevin Steppe <ks...@pacbell.net>.
I'm mostly conjecturing here, so Ceki may have better info, but...
If you have multiple async-appenders going to a single file you could be in
trouble. File writing is all synchronized in the bowels of java.io, but
renaming depends on your specific implementation of FileSystem. It's entirely
possible that file renaming is not really thread safe.
I have a two suggestions:
Use a different log file for each async-appender: no chance of lock collisions
among appenders
Use CompositeRollingAppender with options so that no file rolling ever occurs --
this requires incrementing backup numbers in the opposite direction (higher
numbers are newer files) but you won't deadlock on rollovers.
Here is a sample config to do that with CompositeRollingAppender:
---------------------------------------------------------------------------
#### Normal Stuff ##########
log4j.rootCategory=debug, R
log4j.appender.R=org.apache.log4j.CompositeRollingAppender
log4j.appender.R.RollingStyle=1 #sets rolling by size only (rolling by time is
possible too)
log4j.appender.R.File=example.log
log4j.appender.R.MaxFileSize=10MB
log4j.appender.R.MaxSizeRollBackups=20
#######################################
########## Important Stuff ###################
log4j.appender.R.CountDirection=1 #makes newer files have higher numbers
log4j.appender.R.staticLogFileName=true #log to the new example.log.x instead of
example.log
###################################
------------------------------------------------------------------------------
Those last two lines are the options to eliminate all file rolling.
Thomas Tuft Muller wrote:
> All,
>
> We have a quite complex application with a lot of threads logging to
> different files (appenders). Most of the logging is done via async-appenders
> ending up in RollingFileAppenders.
>
> A couple of times a rolling of the main log file cause a deadlock/starvation
> of all threads in the application. This is a very serious fault (class A).
>
> Anyone expericenced something similar? Any bugfix?
>
> --
>
> Thomas
>
> *************************************************************************
> Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved.
> Confidential. No liability whatsoever is accepted for any loss or damage
> suffered as a result of accessing this message or any attachments.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org