You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2006/07/18 15:46:50 UTC
DO NOT REPLY [Bug 17887] - RollingFileAppender does not work for 10 threads
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=17887>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=17887
yves.debilloez@kbc.be changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WORKSFORME |
------- Additional Comments From yves.debilloez@kbc.be 2006-07-18 13:46 -------
I also have this problem but are unable to generate a test scenario. It occurs
only under heavy load after a few hours of running.
Could problem be related to the code in subAppend method? It seems to be
related to the null-pointer exceptions issues in the subAppend method.
If one thread rolls over, the fileName might temporarily be reset to null. A
second thread will write using a null filename.
I added a test in subAppend before calling the super method. It resolves my
case but it is not a full solution because there is still some theoretical problem.
protected
void subAppend(LoggingEvent event) {
if(fileName != null)
super.subAppend(event);
if((fileName != null) &&
((CountingQuietWriter) qw).getCount() >= maxFileSize)
this.rollOver();
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org