franz1981 edited a comment 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 and `AsyncQueueFullPolicy` already expose some of these: I still see a value in using an unbounded q especially if compared with policies that would change the logs order or block the application threads. If the unbounded q path is feasable, on `JCTools` we have some option that perform great under heavy contention eg xadd qs. The nice thing is that a "mild form" of backpressure is still possible with such alternativies by carefully choosing how to replicate the "object pooling" feature of the Disruptor and use the fixed capacity of such pool to limit the backlog on the unbounded q. -- 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
