vy commented on PR #4038:
URL: https://github.com/apache/logging-log4j2/pull/4038#issuecomment-3982958085

   > > Would you mind pushing some changes (e.g., fix a typo 😅, merge changes 
from upstream/2.x) to get it re-activated, please?
   > 
   > Sure, pushed an empty commit, and it looks like it's now waiting for your 
approval to run again.
   
   Thanks — approved it.
   
   > > There are several ways to achieve this, and they are all covered in 
[Asynchronous 
logging](https://logging.apache.org/log4j/2.x/manual/performance.html#async). 
Have you also experimented with asynchronous appenders? If so, have you also 
tried [customizing its 
queue](https://logging.apache.org/log4j/2.x/manual/appenders/delegating.html#BlockingQueueFactory)?
   > 
   > No, we haven't tried asynchronous appenders, because their blocking queue 
component didn't seem to fit our event loop use-case that well.
   
   Note the [customizing its 
queue](https://logging.apache.org/log4j/2.x/manual/appenders/delegating.html#BlockingQueueFactory)
 link I've shared earlier. It explains how you can replace its queue backend, 
and there are non-blocking alternatives. Would it be possible to give this a 
try and share the outcome with us, please?
   
   I'm insisting on this subject, because asynchronous loggers constitute the 
biggest complexity in the entire Log4j code base. Judging from my personal 
experience, many users choose this setup because they want their logging 
backend to be _"fast"_. Though many times this decision lacks rigorous 
experiments backed with numbers, and exclude simpler alternatives, e.g., using 
asynchronous appender in combination with a [Conversant 
Disruptor](https://github.com/conversant/disruptor) queue. In the long run, we 
really want to move away from this complexity, or, at least, confine it to an 
isolated module. We need help from community to drive this simplification 
effort.


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to