any plans for using LMAX's Disruptor technology for asynchronous logging?
Log4J2 is. I recently stumbled across this link http://logging.apache.org/log4j/2.x/manual/async.html where they claim spectacular results. In particular, Log4J2's AsyncLogger blows away Logback's AsyncAppender. It looks like several people have done their own experiments to have Logback use Disruptors for aynchronous logging. For example: https://github.com/reactor/reactor/tree/master/reactor-logback And this guy posted his results on Logback's user email list: http://mailman.qos.ch/pipermail/logback-user/2013-August/004201.html I would like to know if there are any official plans to incorporate LMAX's Disruptor (or some equivalent) technology in Logback. I searched this list, and could find no discussion. From my perspective, this is critical: fast asynchronous logging is of extreme importance for my current employer, and I bet many other people too.
On Mon, Feb 24, 2014 at 11:19 PM, Brent <yhbrent@yahoo.com> wrote:
Log4J2 is. I recently stumbled across this link http://logging.apache.org/log4j/2.x/manual/async.html where they claim spectacular results. In particular, Log4J2's AsyncLogger blows away Logback's AsyncAppender.
It looks like several people have done their own experiments to have Logback use Disruptors for aynchronous logging. For example: https://github.com/reactor/reactor/tree/master/reactor-logback And this guy posted his results on Logback's user email list: http://mailman.qos.ch/pipermail/logback-user/2013-August/004201.html
I would like to know if there are any official plans to incorporate LMAX's Disruptor (or some equivalent) technology in Logback. I searched this list, and could find no discussion.
No official plans yet, but I'm interested in incorporating it. We recently mentioned Disruptor briefly in [1]. [1] https://github.com/qos-ch/logback/pull/170
From my perspective, this is critical: fast asynchronous logging is of extreme importance for my current employer, and I bet many other people too.
Tony,
any plans for using LMAX's Disruptor technology for asynchronous logging?
No official plans yet, but I'm interested in incorporating it. We recently mentioned Disruptor briefly in [1]. [1] https://github.com/qos-ch/logback/pull/170
Thanks for the link. The discussion there concerns SocketAppender. From what I know about Disruptors, they are a very general queue, and so should be a fine solution for SocketAppender too. My team never logs to sockets, only to the local drive. So, I want Disruptors used inside AsyncAppender. Or, for top performance, be directly used inside FileAppender (or some new class, call it FastFileAppender, if the existing FileAppender cannot be refactored). Just out of curiosity: why does SocketAppender have an internal queue (regardless of type)? If the user wants to asynchonously log to a socket, could they not wrap a simple (synchronous) socket appender with an AsyncAppender, just like you have to do with other appenders (e.g. FileAppender )? Perhaps the thinking was that asynchronous logging to a socket is the only mode that makes sense, since the writes are even slower than to, say, a local disk, so it is even more important that the calling thread quickly return?
participants (2)
-
Brent -
Tony Trinh