CODEWITHSUNDEEP
javalogginglogbackslf4j
anuni
anuni

Reputation: 999

About logback's AsyncAppender

When I check the doc of AsyncAppender in logback, I didn't find something like thread pool setting which support AsyncAppender.

Does that mean there's only 1 thread to consume log events from the blocking queue? (while the log events could be produced by multiple threads, say 20-40)

Thanks

Leon

Upvotes: 0

Views: 1889

Answers (2)

glytching
glytching

Reputation: 47885

From the docs:

AsyncAppender buffers events in a BlockingQueue. A worker thread created by AsyncAppender takes events from the head of the queue, and dispatches them to the single appender attached to AsyncAppender.

And looking at the code; the AsyncAppenderBase starts a single instance of a Thread to take events from the appender's blockingQueue.

So, yes, there is only one worker thread and this thread is responsible for consuming log events which may be emitted by multiple application threads.

If you are concerned that this worker thread may not be able to handle these events as quickly as they are produced then you can tweak the following properties:

  • queueSize: The maximum capacity of the blocking queue. By default, queueSize is set to 256.
  • discardingThreshold: By default, when the blocking queue has 20% capacity remaining, it will drop events of level TRACE, DEBUG and INFO, keeping only events of level WARN and ERROR. To keep all events, set discardingThreshold to 0.

You can increase the queueSize to ensure that you lose no events (albeit at the cost of resource usage since the retained events would sit on your application's heap until they are dispatched to the underlying appender). Or, you can improve performance - at the cost of losing lower priority events - by setting the discardingThreshold.

Upvotes: 2

Andrew Charneski
Andrew Charneski

Reputation: 488

I haven't checked the source code, but I'm fairly sure that yes there is a single thread in the pool. The reason is that it would make very little sense to multithread this process, since the nature of the task is single-threaded. Consider if you are writing to a file: It is impossible to append two messages at the same time to a single file.

Perhaps you expect the string formatting and the toString methods to be invoked off-thread... I expect they will not be, since the arguments to the log message are likely to be modified shortly after the call. The synchronicity is mostly to prevent I/O blockage, such as disk latency, from impacting performance-critical code.

Upvotes: 0

Related Questions