reducing resource contention in logback

Hello all, Ralph and I had a lengthy chat discussing his contribution in LBCLASSIC-35 http://jira.qos.ch/browse/LBCLASSIC-35 For the public record, here is a brief summary of the exchange. His premise is that by carefully modifying synchronization in the AppenderBase and Logger classes we can significantly reduce contention among various threads using logback. The changes must preserve logging event atomicity. For example, if event0 consist of a message m0 and exception e0, and event1 consist of message m1, when an appender writes event0 and event1, possibly sent by different threads, the output must never be m0,m1,e0 but always m0,e0,m1 or alternatively m1,m0,e0. In other words, event intermingling is disallowed even if event ordering is not guaranteed. Raph modified the Logger class so that iterating on the appenders is done without locking. He currently uses ConcurrentHashMap. I think that CopyOnWriteArrayList would also work fine and result in simpler code. Ralph has also modified the doAppend method in AppenderBase pushing the synchronization point to within each derived appender class. Thus it becomes the responsibility of each appender to manage its own synchronization. These changes open the way for threads which support concurrent calls to be invoked without any contention by multiple threads. Of course, the underlying resource, where the logging output is eventually written to, still remains as a contention point. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
participants (1)
-
Ceki Gulcu