Summary: | Queue reading thread in AsyncAppender blocks if a called appender throws a RuntimeException | ||
---|---|---|---|
Product: | Log4j - Now in Jira | Reporter: | Bojan <bojan.kalan> |
Component: | Appender | Assignee: | log4j-dev <log4j-dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | j.c.yip |
Priority: | P3 | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other |
Description
Bojan
2003-09-09 09:17:26 UTC
From what I can tell, this should occur at AppenderAttachableImpl.appendLoopOnAppenders. Surround appender.doAppend(event) with a try catch Runtime, log, and continue. This will prevent a single faulty appender from preventing logging to other appenders and killing the parent loop. As in this: try { appender.doAppend(event); } catch (RuntimeException e) { LogLog.error("Error appending to " + appender, e); } 1.2.12 candidate I'm a little troubled by the proposed resolution. An Appender should not throw a run-time exception and the exception would not be caught if the appender was directly attached to the logger hierarchy. I'd really prefer not to suggest that an appender that throws run-time exceptions is tolerable as long as you wrap it in an async appender. I'm not sure of the cost of the try/catch block in the async appender for the run-time exception that should never come, but it could be expensive enough to be noticable. My current preference is to check dispatcher.isAlive() at the start of AsyncAppender.doAppend and if the dispatch thread has died to invoke the nested appenders synchronously. This should result in similar behavior for both the sync and async other than your first exception is silent if wrapped in an async appender. Fixed on both 1.2 and CVS HEAD. If thread is dead on entry to AsyncAppender.append (possibly from a earlier run-time exception), then logging event will be processed synchronously. |