DO NOT REPLY [Bug 28006] New: - AsyncAppender: Dispatcher should run at normal prio

[bu...@apache.org]

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: log4j-dev@jakarta.apache.org
        ReportedBy: schulz@videotron.ca


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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org