franz1981 commented on pull request #485: URL: https://github.com/apache/logging-log4j2/pull/485#issuecomment-817144692
@jvz > Can you add a manual entry for this as well? Done! @carterkozak > Alternatively a separate JCToolsAsyncAppender is an option. I would go into this direction instead :) TBH the existing disruptor solution is a better fit in term of features set: 1. FIFO (I suppose that's mandatory right? If we just need FIFO for the same thread, there are much faster options on JCTools ala https://github.com/JCTools/JCTools/blob/master/jctools-core/src/main/java/org/jctools/queues/MpscCompoundQueue.java#L136 ie using a fixed size of queues to distribute contention on the tail) 2. Object pool: this is unbeatable 3. batch-friendly: no idea how much this feature is used on log4j, but it can be rather important while appending files to batch writes syscalls (on `FileChannel` `pwrite`). Thinking about a `JCToolsAsyncAppender` I still need to understand if being bounded is such a must have: I'm a great fan of backpressure, really, but with logging...is different. I see different strategies that could be employed to satisfy different application needs: - if is ok to slow down application threads: retry submitting log events until consumer can keep up - if is not ok to slow down application threads: drop logs (using a bounded q and picking incoming ones in LIFO/FIFO order depending which to prefer) or just offer logs to an unbounded q Although the unbounded q seems a terrible idea, I see different cases where blocking producers can cause the same thing, but stealthy: if there is a `ReentrantLock` to protect a full q (or something similar), it just means that the number of parked producer threads can grow unbounded as well (causing both GC issues and disturbing applications that manybe have enough room for GC instead). If there is no lock to protect from that state, instead, but a simple retry mechanism, the backpressure can hit the application threads instead, that were not prepared to handle a logging action blocked for "too much" time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
