[logback-dev] [JIRA] Commented: (LBCORE-97) Starvation on AppenderBase.doAppend

[Robert Elliot]

Just as an academic question, what do you think of an architecture  
where the various debug/info/error etc. calls on Logger all put  
something like a LoggingEvent (though probably an immutable  
equivalent) on a blocking queue, and a single thread takes events off  
the top of the queue and calls the appenders with it?

Then appender calls would be done in a single threaded way, and so an  
appender implementation would not need to worry about thread safety.

My take on the pros and cons of such an architecture:

Pros:
Using the proven j.u.concurrent queues for thread safety is simpler  
and safer than rolling your own
No need for individual appender implementations to worry about thread  
safety
An application thread isn't slowed down by the I/O involved in appending

Cons:
Makes your app multi-threaded even in a single threaded environment  
(mind you, using just about any JVM does this anyway...)
The single consumer thread may be flooded by multiple producer  
application threads, particularly in a web app where you may have a  
large number of threads logging - that's a memory leak unless you use  
a bounded buffer, and if you use a bounded buffer then you may  
suddenly find yourself with random delays as the application threads  
block waiting for the logging consumer thread to take events off the  
queue.  However, you could mitigate this by deliberately making  
particular appenders hand off their work asynchronous so that you had  
more threads doing the actual logging work.

Not seriously suggesting that Logback makes such a radical change in  
architecture, just wondering what people thought of the concept - is  
there something I'm missing?  Would the problem Joern is experiencing  
with multiple threads competing for a lock and only one of them  
getting the lock still occur?