logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy Chastain (Assigned) (JIRA)" <j...@apache.org>
Subject [jira] [Assigned] (LOG4NET-175) RollingFileAppender generates unexpected filename and/or causes IIS to hang
Date Wed, 28 Sep 2011 12:17:46 GMT

     [ https://issues.apache.org/jira/browse/LOG4NET-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Roy Chastain reassigned LOG4NET-175:

    Assignee:     (was: Roy Chastain)
> RollingFileAppender generates unexpected filename and/or causes IIS to hang
> ---------------------------------------------------------------------------
>                 Key: LOG4NET-175
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-175
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 1.2.9
>         Environment: win32
>            Reporter: Devan Iyer
>             Fix For: 1.2 Maintenance Release
>   Original Estimate: 2h
>  Remaining Estimate: 2h
> 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 "abc_%date{yyyyMMdd_HHmmss}_%processid_.log".
> We have observed in our production environment that occasionally filenames would be created
with patterns like "abc_%date{yyyyMMdd_HHmmss}_%processid_.log.1", "abc_%date{yyyyMMdd_HHmmss}_%processid_.log.1.2",
"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 observed.
> 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 created.
> 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 permission.
> - Launch our application and view another document.
> - At this point a logfile with a filename pattern described will be found in the logging
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message