logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Georg Jansen <Georg.Jan...@Faktnet.com>
Subject RE: RollingFileAppender generates unexpected filename and/or causes IIS to hang
Date Thu, 18 Sep 2008 18:49:32 GMT


You use:


appendToFile=false (I always want a new file)

And you have RollingStyle=Once (this by default sets the appendToFile to


What I think happen is that every time log4Net needs to open a log file it
opens a new file (whenever a worker process starts), and that is the reason
for the sequential thing, are you sure you don't want RollingStyle=Date? 


But I am uncertain about the kind of naming schema you try to accomplish?
Maybe you could explain it  - it would make it easier to make a proposal.


You also use the %processId as a part of the filename pattern. I just want
to mention that as far as I know you will have one processeId for each
worker process (can be several depending on the setup). Requests from the
same client can be served by different worker processes - this could
possibly make it hard to follow one client through the logs (if you need



Best regards


 <http://www.l4ndash.com> http://www.l4ndash.com - log4net dashboard





From: Iyer, Devan [mailto:devan.iyer@sap.com] 
Sent: 16. september 2008 22:09
To: log4net-user@logging.apache.org
Subject: RollingFileAppender generates unexpected filename and/or causes IIS
to hang


We are using rolling file appender in an IIS managed C# application. Our
log4Net deployment is configured with the following options specified in
basic.xml: <appendToFile value="false" /> <countDirection value="0" />
<maximumFileSize value="512KB" /> <maxSizeRollBackups value="100" />
<rollingStyle value="Once" /> <staticLogFileName value="false" />. The file
pattern for our log file name is

We have observed in our production environment that occasionally filenames
would be created with patterns like
"abc_%date{yyyyMMdd_HHmmss}_%processid_.log.1.2.3", etc. We have observed
filenames with the dot+sequential numbers pattern after the .log to be
anything from ".1" to ".220". This is one of two unexpected behaviours


The second unexpected behaviour seems to a special case of the first that
occasionally causes IIS to hang (100% CPU consumption). An analysis of
several crash dumps taken at the time of the hang indicated that
RollingFileAppender had in memory a filename of the same pattern as above
but with the number of characters [base filename pattern]+[recurring
extension pattern] exceeding 255 characters. It is very likely that an
attempt to create a file by such name on NTFS would throw exceptions at
various levels - managed and native - and hence the file itself is never


To the best of our knowledge, there were no events to trigger the filename
to be rolled. As indicated in the configuration options, we are using
RollingStyle of "Once". (The log file content is minimal at the time the
symptoms occur - total file size is about 2K - and the times of occurrence
are totally non related).


We have been unable to capture the workflow leading up to the symptoms above
due to the high number of users and document types in our production
environment. The permissions on the logging folder are static. However, we
have found a simple workflow in our lab environment, using permissions, that
produce similar symptoms. This workflow is:


- Right click on the logging folder and select "Properties"

- Under the "Security" tab ensure that IIS_WPG group doesn't have write
access to the logging folder.

- Restart IIS

- Launch our application and view a document.  Check the logging folder to
make sure that a logfile is not created.

- View a few more documents

- Change the permission on the logging folder and ensure IIS_WPG group has
write access to the folder.  DO NOT restart IIS after changing the

- Launch our application and view another document.

- At this point a logfile with a filename pattern described will be found in
the logging folder.


As mentioned, it is unlikely that permissions are the trigger in our event
but it is likely that the same code is creating these unexpected patterns
irrespective of the trigger.

View raw message