gmane.comp.apache.logging.log4net.devel

Re: Configuration system enhancement

François Dumont — 2008-10-06T19:37:43

Well, I have looked at test cases and haven't found what I am trying to do. In fact I simply would like to know if you have ever considered adopting the .Net 2.0 ConfigurationSection system as for the moment log4net only use the IConfigurationSectionHandler. In a number of situations the ConfigurationSection would be more convenient. Here are 2 use cases where I could have advantage of it: - application specific log file: We are developing Windows services that can be instantiated numerous times, each service instance having its own name. All services are using the same log4net configuration file and we prefer to have all services log to the same 'logs' folder. So the problem is to specialize the log file name for each service. We do so thanks to an environment variable that each process has to set at startup containing the service name, the file name in the log4net config file contains a %ENV_VAR% that is automatically replaced when log4net starts. - Custom appender with non serializable fields: We have a custom appender to perform asynchronous log. This appender creates for the moment its own thread to work but I would prefer to have the application creates it and assign it to the log4net appender. The only solution I found so far is to have some kind of thread singleton instance in the global scope of the application and then have the appender retrieve it at construction. You see in both situation I have to rely on a global storage which is a design I always try to avoid because of the thread safety or maintenance problems that comes with it. The following configuration would be much more convenient: - For the file customization I would prefer something like that: Log4NetConfigurationSection section = (Log4NetConfigurationSection)ConfigurationManager.GetSection("log4net"); string fileName = section.Appenders["FileAppender"].Properties["File"].ToString(); section.Appenders["FileAppender"].Properties["File"] = fileName.Replace("%SERVICE_NAME%", "Foo"); Log4NetConfigurator.Configure(section); - For the thread problem I would see something like that: Log4NetConfigurationSection section = (Log4NetConfigurationSection)ConfigurationManager.GetSection("log4net"); Thread logThread = new Thread(); logThread.Name = "Log thread"; logThread.Start(); foreach (Appender appender in section.Appenders) { if (appender.Type == typeof(AsyncAppender)) { appender.Properties["thread"] = logThread; } } Log4NetConfigurator.Configure(section); Of course the Appenders property would return an AppenderCollection containing instances of a class which serialization is the config element. So the idea is to have most of the configuration set in a config file but still be able to tweak it programmatically. I hope I have been clear this time. Bests Ron Grabowski wrote:

[jira] Created: (LOG4NET-179) Log file does not get created by release version of App.exe

Shetal Shah (JIRA — 2008-10-06T18:49:44

Log file does not get created by release version of App.exe ----------------------------------------------------------- Key: LOG4NET-179 URL: https://issues.apache.org/jira/browse/LOG4NET-179 Project: Log4net Issue Type: Test Affects Versions: 1.2.10 Environment: Visual Studio 2005, language C#, OS Windows XP Professional Reporter: Shetal Shah I have a windows application that uses log4net. My app.config section has

When I build my exe in debug mode and run it, it works fine and log4net.Repository.ILoggerRepository RootRep; RootRep = log4net.LogManager.GetRepository(); RootRep is configured and has one appender. Now, same code but when I compile the exe in release mode, it does not create log file. RootRep is not configured and it has 0 appender. I am not sure what is different between debug and release exe. Any help is greatly appriciated. Thanks Shetal Shah

[jira] Created: (LOG4NET-178) Log4Net stops logging after appdomain recycle of aps.net2.0 application

Richard Nijkamp (JIRA — 2008-10-06T08:37:45

Log4Net stops logging after appdomain recycle of aps.net2.0 application ----------------------------------------------------------------------- Key: LOG4NET-178 URL: https://issues.apache.org/jira/browse/LOG4NET-178 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows server 2003 Reporter: Richard Nijkamp Dear sir/madam, We are using Log4Net 1.2.10. We encounter the problem that Log4net doesn't continue logging after an event that triggers an appdomain recycle/restart. In the global.asax we start the logging with: private static readonly ILog log = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType); Logging works flawless when the application is started for the first time. After sometime it might occur that the appdomain gets recycled due to inactivity of the web application. We use the following code in Application_end(): log.Info("*** Application end ***"); log4net.LogManager.Shutdown(); After this function the application gets restarted and the Application_start() method executes and writes new lines to the log. The problem is that the log4net doesn't write the new lines after the restart. Could you explain why log4net might stop working after an appdomain restart of an asp.net2.0 web application? If I want log4net to work properly again I need to restart IIS manually. Looking forward to your reply. Best regards, Richard Nijkamp

[jira] Created: (LOG4NET-177) How to get the pattern convert string form layout?

anvy0314 (JIRA — 2008-10-06T08:11:44

How to get the pattern convert string form layout? -------------------------------------------------- Key: LOG4NET-177 URL: https://issues.apache.org/jira/browse/LOG4NET-177 Project: Log4net Issue Type: Test Affects Versions: 1.2.10 Reporter: anvy0314 Hi, I want to get the whole string after pattern format, how to do it, thanks! Like this string "2008-10-06 15:50:45,875 [192.168.7.103] DEBUG PingTestLogger..." before write to the log file.

[jira] Updated: (LOG4NET-176) Buildable with VS 2008 and .NET FW 3.5

Nicklas Norling (JIRA — 2008-10-04T13:21:44

[ https://issues.apache.org/jira/browse/LOG4NET-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicklas Norling updated LOG4NET-176: ------------------------------------ Attachment: Vs2k8.net35.patch Patch against trunk for vs2008 and .net 3.5 buildability

[jira] Created: (LOG4NET-176) Buildable with VS 2008 and .NET FW 3.5

Nicklas Norling (JIRA — 2008-10-04T13:19:44

Buildable with VS 2008 and .NET FW 3.5 -------------------------------------- Key: LOG4NET-176 URL: https://issues.apache.org/jira/browse/LOG4NET-176 Project: Log4net Issue Type: New Feature Components: Builds Environment: Windows, log4net trunk, vs 2008 .net 3.5 Reporter: Nicklas Norling Priority: Minor Fix For: v.Next Providing a patch for the changes I'm using when compiling log4net locally using vs2008 and .net 3.5. The patch is created against trunk < at > 701632. It adds project and solution files for vs 2008, adds compilation symbol NET_3_5 which is then added to all conditional compilation statements that have NET_2_0 today. Also the AssemblyInfo.cs has a .NET 3.5 section added. Since the project files have to be manually updated when new files are added to trunk I would appretiate it if this patch (or one with similar functions) where added to trunk.

Re: Appender to run at a Schedule Time

Ron Grabowski — 2008-10-02T21:17:02

Use a Timer? // untested public class AutoFlushSmtpAppender : SmtpAppender { private System.Timers.Timer timer; private int interval; ///

/// Flush interval in milliseconds. ///

public int Interval { get { return interval; } set { interval = value; } } public override void ActivateOptions() { base.ActivateOptions(); ErrorHandler = new StopTimerErrorHandler(this, ErrorHandler); timer = new Timer(Interval); timer.Elapsed += delegate { Flush(); }; timer.Start(); } protected override void OnClose() { stopTimer(); base.OnClose(); } private void stopTimer() { if (timer.Enabled) { timer.Enabled = false; timer.Stop(); } } class StopTimerErrorHandler : IErrorHandler { private readonly AutoFlushSmtpAppender appender; private readonly IErrorHandler wrapped; public StopTimerErrorHandler(AutoFlushSmtpAppender appender, IErrorHandler wrapped) { this.appender = appender; this.wrapped = wrapped; } public void Error(string message, Exception e, ErrorCode errorCode) { appender.stopTimer(); wrapped.Error(message, e, errorCode); } public void Error(string message, Exception e) { appender.stopTimer(); wrapped.Error(message, e); } public void Error(string message) { appender.stopTimer(); wrapped.Error(message); } } } ----- Original Message ---- From: HemantJPatel hotmail.com> To: log4net-dev< at >logging.apache.org Sent: Tuesday, September 30, 2008 11:29:53 AM Subject: Appender to run at a Schedule Time Hi, I need to run the smtp appender at a specified interval of time. Any ideas how I can do this to that the appender will run at specific intervals and send all the buffered messages. Any pointers will be helpful. Thanks in advance. Thanks, Hemant

Re: Configuration system enhancement

Ron Grabowski — 2008-10-01T20:58:34

Log4net can be configured progmatically. Have you looked at the test cases for examples? ----- Original Message ---- From: François Dumont free.fr> To: log4net-dev< at >logging.apache.org Sent: Wednesday, October 1, 2008 3:34:28 PM Subject: Configuration system enhancement Hi We are using log4net through out all our applications and are very happy with it. I would like to know however if you ever considered enhancing the configuration system. I would be especially interested in being able to fully initialize log4net programmatically. All the sample I have been able to find are always using an xml description but there are parameters we need to pass to a special appender we have develop that simply cannot be serialized. Bests François Dumont

Configuration system enhancement

François Dumont — 2008-10-01T19:34:28

Hi We are using log4net through out all our applications and are very happy with it. I would like to know however if you ever considered enhancing the configuration system. I would be especially interested in being able to fully initialize log4net programmatically. All the sample I have been able to find are always using an xml description but there are parameters we need to pass to a special appender we have develop that simply cannot be serialized. Bests François Dumont

Appender to run at a Schedule Time

HemantJPatel — 2008-09-30T15:29:53

Hi, I need to run the smtp appender at a specified interval of time. Any ideas how I can do this to that the appender will run at specific intervals and send all the buffered messages. Any pointers will be helpful. Thanks in advance. Thanks, Hemant

[jira] Commented: (LOG4NET-175) RollingFileAppender generates unexpected filename and/or causes IIS to hang

Devan Iyer (JIRA — 2008-09-29T23:12:44

[ https://issues.apache.org/jira/browse/LOG4NET-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635582#action_12635582 ] Devan Iyer commented on LOG4NET-175: ------------------------------------ I solved this one: This behaviour is due to RollingFileAppender and it's base class FileAppender not resetting certain private member variables when an OpenFile call fails. RollingFileAppender.OpenFile (filename, bAppend) always does a GetNextOutputFileName(fileName) before calling the base class OpenFile. This appends the string value of m_curSizeRollBackups to filename. FileAppender.OpenFile (filename, bAppend) stores in private member variables the value of the arguments filename and bAppend and then attempts to create a LockingStream. This fails with a LockStateException which is not handled. The correct approach would be to roll back the values of m_fileName, m_appendToFile , m_curSizeRollBackups and m_scheduledFilename when the OpenFile call fails. I accomplished this in my subclass as follows: protected override void OpenFile(string fileName, bool append) { bool oldAppend = this.AppendToFile; string oldFileName = this.File; try { base.OpenFile (fileName, append); } catch (log4net.Core.LogException ex) { LogLog.Debug ("CERollingFileAppender.OpenFile, base.OpenFile (fileName, append) threw an exception, " + ex.Message); base.File = oldFileName; // easily set by protected property access base.AppendToFile = oldAppend; // easily set by protected property access base.ExistingInit (); // no access to m_curSizeRollBackups and m_scheduledFilename but this will do it. } } Ideally this fix should be in the core RollingFileAppender, FileAppender implementations with appropriate additional configuration status checks.

[jira] Issue Comment Edited: (LOG4NET-175) RollingFileAppender generates unexpected filename and/or causes IIS to hang

Devan Iyer (JIRA — 2008-09-29T23:12:44

[ https://issues.apache.org/jira/browse/LOG4NET-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635582#action_12635582 ] devan.iyer edited comment on LOG4NET-175 at 9/29/08 4:12 PM: ------------------------------------------------------------- I solved this one: This behaviour is due to RollingFileAppender and it's base class FileAppender not resetting certain private member variables when an OpenFile call fails. RollingFileAppender.OpenFile (filename, bAppend) always does a GetNextOutputFileName(fileName) before calling the base class OpenFile. This appends the string value of m_curSizeRollBackups to filename. FileAppender.OpenFile (filename, bAppend) stores in private member variables the value of the arguments filename and bAppend and then attempts to create a LockingStream. This fails with a LockStateException which is not handled. The correct approach would be to roll back the values of m_fileName, m_appendToFile , m_curSizeRollBackups and m_scheduledFilename when the OpenFile call fails. I accomplished this in my subclass as follows: protected override void OpenFile(string fileName, bool append) { bool oldAppend = this.AppendToFile; string oldFileName = this.File; try { base.OpenFile (fileName, append); } catch (log4net.Core.LogException ex) { LogLog.Debug ("MyClass.OpenFile, base.OpenFile (fileName, append) threw an exception, " + ex.Message); base.File = oldFileName; // easily set by protected property access base.AppendToFile = oldAppend; // easily set by protected property access base.ExistingInit (); // no access to m_curSizeRollBackups and m_scheduledFilename but this will do it. } } Ideally this fix should be in the core RollingFileAppender, FileAppender implementations with appropriate additional configuration status checks. was (Author: devan.iyer): I solved this one: This behaviour is due to RollingFileAppender and it's base class FileAppender not resetting certain private member variables when an OpenFile call fails. RollingFileAppender.OpenFile (filename, bAppend) always does a GetNextOutputFileName(fileName) before calling the base class OpenFile. This appends the string value of m_curSizeRollBackups to filename. FileAppender.OpenFile (filename, bAppend) stores in private member variables the value of the arguments filename and bAppend and then attempts to create a LockingStream. This fails with a LockStateException which is not handled. The correct approach would be to roll back the values of m_fileName, m_appendToFile , m_curSizeRollBackups and m_scheduledFilename when the OpenFile call fails. I accomplished this in my subclass as follows: protected override void OpenFile(string fileName, bool append) { bool oldAppend = this.AppendToFile; string oldFileName = this.File; try { base.OpenFile (fileName, append); } catch (log4net.Core.LogException ex) { LogLog.Debug ("CERollingFileAppender.OpenFile, base.OpenFile (fileName, append) threw an exception, " + ex.Message); base.File = oldFileName; // easily set by protected property access base.AppendToFile = oldAppend; // easily set by protected property access base.ExistingInit (); // no access to m_curSizeRollBackups and m_scheduledFilename but this will do it. } } Ideally this fix should be in the core RollingFileAppender, FileAppender implementations with appropriate additional configuration status checks.

[jira] Created: (LOG4NET-175) RollingFileAppender generates unexpected filename and/or causes IIS to hang

Devan Iyer (JIRA — 2008-09-29T23:10:45

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

Re: RollingFileAppender generates unexpected filename and/or causes IIS to hang

Ron Grabowski — 2008-09-25T00:00:11

Thank you for looking into this. I'll review your comments. The best thing to do would be to create and upload a patch on Jira: https://issues.apache.org/jira/browse/LOG4NET ----- Original Message ---- From: "Iyer, Devan" sap.com> To: log4net-user< at >logging.apache.org; log4net-dev< at >logging.apache.org Sent: Wednesday, September 24, 2008 4:09:37 PM Subject: RE: RollingFileAppender generates unexpected filename and/or causes IIS to hang I solved this one: This behaviour is due to RollingFileAppender and it's base class FileAppender not resetting certain private member variables when an OpenFile call fails. RollingFileAppender.OpenFile (filename, bAppend) always does a GetNextOutputFileName(fileName) before calling the base class OpenFile. This appends the string value of m_curSizeRollBackups to filename. FileAppender.OpenFile (filename, bAppend) stores in private member variables the value of the arguments filename and bAppend and then attempts to create a LockingStream. This fails with a LockStateException which is not handled. The correct approach would be to roll back the values of m_fileName, m_appendToFile , m_curSizeRollBackups and m_scheduledFilename when the OpenFile call fails. I accomplished this in my subclass as follows: protected override void OpenFile(string fileName, bool append) { bool oldAppend = this.AppendToFile; string oldFileName = this.File; try { base.OpenFile (fileName, append); } catch (log4net.Core.LogException ex) { LogLog.Debug ("CERollingFileAppender.OpenFile, base.OpenFile (fileName, append) threw an exception, " + ex.Message); base.File = oldFileName; // easily set by protected property access base.AppendToFile = oldAppend; // easily set by protected property access base.ExistingInit (); // no access to m_curSizeRollBackups and m_scheduledFilename but this will do it. } } Ideally this fix should be in the core RollingFileAppender, FileAppender implementations with appropriate additional configuration status checks. ________________________________ From: Iyer, Devan Sent: September 16, 2008 1:09 PM To: log4net-user< at >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: . 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.

RE: RollingFileAppender generates unexpected filename and/or causes IIS to hang

Iyer, Devan — 2008-09-24T20:09:37

I solved this one: This behaviour is due to RollingFileAppender and it's base class FileAppender not resetting certain private member variables when an OpenFile call fails. RollingFileAppender.OpenFile (filename, bAppend) always does a GetNextOutputFileName(fileName) before calling the base class OpenFile. This appends the string value of m_curSizeRollBackups to filename. FileAppender.OpenFile (filename, bAppend) stores in private member variables the value of the arguments filename and bAppend and then attempts to create a LockingStream. This fails with a LockStateException which is not handled. The correct approach would be to roll back the values of m_fileName, m_appendToFile , m_curSizeRollBackups and m_scheduledFilename when the OpenFile call fails. I accomplished this in my subclass as follows: protected override void OpenFile(string fileName, bool append) { bool oldAppend = this.AppendToFile; string oldFileName = this.File; try { base.OpenFile (fileName, append); } catch (log4net.Core.LogException ex) { LogLog.Debug ("CERollingFileAppender.OpenFile, base.OpenFile (fileName, append) threw an exception, " + ex.Message); base.File = oldFileName; // easily set by protected property access base.AppendToFile = oldAppend; // easily set by protected property access base.ExistingInit (); // no access to m_curSizeRollBackups and m_scheduledFilename but this will do it. } } Ideally this fix should be in the core RollingFileAppender, FileAppender implementations with appropriate additional configuration status checks. ________________________________ From: Iyer, Devan Sent: September 16, 2008 1:09 PM To: log4net-user< at >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: . 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.

[jira] Commented: (LOG4NET-172) Web Service Appender

Brandon Wood (JIRA — 2008-09-22T15:44:44

[ https://issues.apache.org/jira/browse/LOG4NET-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633353#action_12633353 ] Brandon Wood commented on LOG4NET-172: -------------------------------------- I originally wrote this appender as simply as possible to get a first version working. As such, it doesn't yet support complex parameters.

[jira] Commented: (LOG4NET-172) Web Service Appender

David Radcliffe (JIRA — 2008-09-22T15:04:44

[ https://issues.apache.org/jira/browse/LOG4NET-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633282#action_12633282 ] David Radcliffe commented on LOG4NET-172: ----------------------------------------- This Appender appears to require VS2005, whereas the rest of log4net requires only VS2002. I have had problems calling a web service which has complex parameters (arrays of UDTs), and have contacted the author directly about this.

Re: How to find where log4net is logging to at runtime

Ron Grabowski — 2008-09-18T22:49:11

Log4net doesn't track that information. Can you store that information on your own in a static variable? ----- Original Message ---- From: lilalfyalien oxfordcc.co.uk> To: log4net-dev< at >logging.apache.org Sent: Thursday, September 18, 2008 6:47:54 AM Subject: How to find where log4net is logging to at runtime Hi, I am using this code to load in an XML config file: FileInfo configFile = new FileInfo("C:\\Log4Net.Config"); log4net.Config.XmlConfigurator.ConfigureAndWatch(configFile); How can I then find out where Log4Net is logging to so I can display this info to my user and tell them to look in the log file at X? Thanks Amy

How to find where log4net is logging to at runtime

lilalfyalien — 2008-09-18T10:47:54

Hi, I am using this code to load in an XML config file: FileInfo configFile = new FileInfo("C:\\Log4Net.Config"); log4net.Config.XmlConfigurator.ConfigureAndWatch(configFile); How can I then find out where Log4Net is logging to so I can display this info to my user and tell them to look in the log file at X? Thanks Amy

RollingFileAppender generates unexpected filename and/or causes IIS to hang

Iyer, Devan — 2008-09-16T20:09:36

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

Re: Same file read/write from Multiple process

Pradeeptp — 2008-09-16T07:27:58

Hi Ron, I checked the link provided by you. The document says that MinimalLock is not thread safe. (PS: I clicked on your reply but I didnt see any reply link to reply to your message, so I am replying to my own message). rgds Pradeep Pradeeptp wrote: