Wildfly Logging - Understanding the Async Handler

[Christoffer A. Nilsen]

I have tried to read about the Wildfly Async Handler, though, have some problems finding detailed documentation.

The way I understand the Async Handler is that; the Async Handler is a separate processes that flush/push the queued lines to my log file(assuming I'm logging to a file). The Async handler's purpose is not to bulk push log lines to the log file, but to reduce the wait time for the main process, by having a separate process do the logging. Meaning a Async Handler does not necessary reduce disk access load.

If the configured Queue Length is to small (with Overflow Action=BLOCK), or the queue is often full, the async handler won't improve performance, and the main thread would have to wait for the queue accept new lines.

Is my understanding of the Async handler correct?

Other Async questions.

I cannot find any documentation about suggested Queue Length, but have found a few Red Hat examples using 512 or 1024. Is there any importance/benefits to using a value that is the power of two? Is there any huge risks to use a very large Queue Length except for OOM issues? What would you suggest as a good Queue Length? We log around 250,000 lines an hour.

[James Perkins]

You're understanding of how the Async handler works is correct. The purpose of it is to return quickly from a log method rather than block until the handler is finished, for example doing some kind of I/O.

The queue-length really needs to be determined by you. 250,000 log messages an hour is a lot. However, how quick your queue is processed depends on the delegate handlers. A large queue would likely not take up that much memory, but it really depends on what you're logging.

Sorry I can't help more there, but it's likely something you're going to have to experiment with.