[ https://issues.apache.org/jira/browse/LOG4NET-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Bodewig updated LOG4NET-175: ----------------------------------- Fix Version/s: 1.2 Maintenance Release > 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 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira