[logback-dev] [JIRA] Commented: (LBCORE-97) Starvation on AppenderBase.doAppend
rob at lidalia.org.uk
Sun May 31 18:51:28 CEST 2009
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:
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
An application thread isn't slowed down by the I/O involved in appending
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?
More information about the logback-dev