You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Steven Myron (JIRA)" <ji...@apache.org> on 2008/08/22 23:00:45 UTC
[jira] Created: (LOG4NET-171) Log file locking causing an error to
be thrown from the RollingFileAppender
Log file locking causing an error to be thrown from the RollingFileAppender
---------------------------------------------------------------------------
Key: LOG4NET-171
URL: https://issues.apache.org/jira/browse/LOG4NET-171
Project: Log4net
Issue Type: Bug
Components: Core
Affects Versions: 1.2.10
Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
Reporter: Steven Myron
Priority: Critical
Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-171) Log file locking causing an error
to be thrown from the RollingFileAppender
Posted by "Steven Myron (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625355#action_12625355 ]
Steven Myron commented on LOG4NET-171:
--------------------------------------
We are trying to work with the client and get the jobs spaced out so they don't have the potential to overlap. This is for a SAP integration project that syncs up data between two disparate systems.
I had been using log4j in a web app environment that had multiple sessions, servlets, and threads logging to the same file in a high volume usage scenerio. We never had any problems with the logging (our hands were full with other issues). We also used a RollingFileAppender (on date/time rather than size).
The Apache website states that is logging is fail-stop and not reliable and if logging is interrupted (database connection, network, "file sharing violation", etc.) that the worst case is that it just doesn't log that event (no problem).
Right now, I am trying a "PatternFileAppender" to change folder/file locations for different plants. I had to create a class from source code I found from a reference on apache.org but not working so far...when log4net configures it is hard to tell if it is configuring properly (which in this case it is not since I am not seeing any appenders)?
Hey, I love this logger and it just caught me by surprise when I saw it crash an application for the first time ever for me? This ain't supposed to happen...
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LOG4NET-171) Log file locking causing an error to
be thrown from the RollingFileAppender
Posted by "Steven Myron (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steven Myron closed LOG4NET-171.
--------------------------------
Resolution: Invalid
Please see my last comment
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-171) Log file locking causing an error
to be thrown from the RollingFileAppender
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625533#action_12625533 ]
Ron Grabowski commented on LOG4NET-171:
---------------------------------------
The problem is that you have two different procesess trying to write/roll the same file. If there are 3 processes writing/rolling the same file how does log4net know when one of the other processes has rolled the file? Log4net can easily handle lots of threads from the same process writing to a rolling file.
The message you're seeing shouldn't be crashing your application. Log4net writes debug information to Console.Out when something bad happens. Your program should continue to function...but logging will be disabled.
The next version of log4net has an improved configuration system that makes it easier to detect configuration errors. Until then you can turn on internal debugging and capture output sent to a System.Diagnostics listener.
If the jobs do overlap is it ok to have mixed output in the same file? Can you log to a database then log to a file if the database goes offline?
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LOG4NET-171) Log file locking causing an error to
be thrown from the RollingFileAppender
Posted by "Steven Myron (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Steven Myron updated LOG4NET-171:
---------------------------------
Attachment: original issue.jpg
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-171) Log file locking causing an error
to be thrown from the RollingFileAppender
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625113#action_12625113 ]
Ron Grabowski commented on LOG4NET-171:
---------------------------------------
If you have a process running and it has an exclusive lock on a file and another process comes along and tries to get the lock it won't be able to get it. Having two processes writing to the same rolling file is generally not a good idea. How would the two processes communicate when/how to role the file? Can you append the process id to the filename so there isn't a conflict?
You could use a normal FileAppender and a MutextLock (see the mailing list for sample code) that would allow two processes to write to the same file.
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LOG4NET-171) Log file locking causing
an error to be thrown from the RollingFileAppender
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625113#action_12625113 ]
ron edited comment on LOG4NET-171 at 8/23/08 2:44 PM:
----------------------------------------------------------------
If you have a process running and it has an exclusive lock on a file and another process comes along and tries to get the lock it won't be able to get it. log4net isn't a database...it doesn't coordinate many processes trying to update a single resource. How do you propose it should handle this scenario?
Having two processes writing to the same rolling file is generally not a good idea. How would the two processes communicate when/how to role the file? Can you append the process id to the filename so there isn't a conflict?
You could use a normal FileAppender and a MutextLock (see the mailing list for sample code) that would allow two processes to write to the same file.
was (Author: ron):
If you have a process running and it has an exclusive lock on a file and another process comes along and tries to get the lock it won't be able to get it. Having two processes writing to the same rolling file is generally not a good idea. How would the two processes communicate when/how to role the file? Can you append the process id to the filename so there isn't a conflict?
You could use a normal FileAppender and a MutextLock (see the mailing list for sample code) that would allow two processes to write to the same file.
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-171) Log file locking causing an error
to be thrown from the RollingFileAppender
Posted by "Steven Myron (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626147#action_12626147 ]
Steven Myron commented on LOG4NET-171:
--------------------------------------
I guess that can be somewhat tricky to manage when Process A is trying to write to a file object while Process B is in the middle of rolling the file...right back to inter-process communication...you first!
Since out program is a console application and is running at a client site, we assumed this was an unhandled error. It is good that this is only a benign System.Console.Out.Write... and no logging on that thread will occur (which is no problem).
We did go with the following to split up some of the logging:
<file type="log4net.Util.PatternString">
<conversionPattern value="logs\%property{prefix}_JobCopDataLoader.log" />
</file>
The above log file naming schema still rolls and archives the logs (which is a good thing). The only catch was that we had to set the ThreadContext.Properties["prefix"] before the call to LogManager.GetLogger() is made.
Mixed output is fine especially if you have tools like Chainsaw or Log4Net Dashboard to filter and clean up the text. Database logging is a better strategy (disconnected clients, network topology, and infrastructure a big part of this decision) and saves the overhead of log file pulls and aggregation. Great idea to have a failover of a physical log file if database connectivity becomes an issue!
Thank you very much for you help and I consider this issue closed.
> Log file locking causing an error to be thrown from the RollingFileAppender
> ---------------------------------------------------------------------------
>
> Key: LOG4NET-171
> URL: https://issues.apache.org/jira/browse/LOG4NET-171
> Project: Log4net
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.10
> Environment: Windows 2003 Server (scheduled jobs/.exe that may be overlapping)
> Reporter: Steven Myron
> Priority: Critical
> Attachments: original issue.jpg
>
> Original Estimate: 120h
> Remaining Estimate: 120h
>
> Scheduled processes (~ 15 minutes apart) seem to be overlapping possibly causing file sharing violations for the log file that log4net is writing to. This file is statically named and is written to using the RollingFileAppender. This abruptly terminates the application and presents an unexpected error to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.