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?
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
