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=28006>. 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=28006 AsyncAppender: Dispatcher should run at normal prio Summary: AsyncAppender: Dispatcher should run at normal prio Product: Log4j Version: 1.2 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Appender AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In a production environment, under load the following scenario developed: - Async buffer filled up, and the proceeding requests took priority over the Dispatcher, - additional requests were blocked, - as the system finished enough requests so that the low prio Dispatcher could run, it proceeded with its appender calls - each event processed, freed another slot for one of the blocked threads, which in turn immediately took over the CPU from the Dispatcher. The end effect was a severly choked system. Even worse, on Solaris the blocked threads are not scheduled fairly, but in nearly-LIFO order, leading to near-arbitrary delays. The priority for the Dispatcher should be normal by default. I don't mind if there are niche use cases which require a low prio for the Dispatcher, but that should then be made optionally configurable. I can provide the simple change, plus a fix for the race condition which can develop between the Dispatcher and the blocked threads when the Dispatcher manages to process 2 events before the next thread inserts one. Drop me a note. To test for this scenario, you need a slow Appender such as a DB appender, or add an artificial delay. As far as I know, this applies 1.2.8 (even though I looked at 1.2.4 for the fix) Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
