Backend Development 5 min read

AsyncAppender OOM, Log Loss, and Blocking Issues – Configuration Guide

The article explains how AsyncAppender uses a BlockingQueue with a default size of 256, how an oversized queue can cause OOM, how the discardingThreshold can lead to loss of TRACE/DEBUG/INFO logs, and provides configuration tips such as adjusting queueSize, setting discardingThreshold to zero, or enabling neverBlock to avoid blocking.

Cognitive Technology Team
Cognitive Technology Team
Cognitive Technology Team
AsyncAppender OOM, Log Loss, and Blocking Issues – Configuration Guide

AsyncAppender buffers logging events in a BlockingQueue whose default capacity is 256 entries, defined by the constant DEFAULT_QUEUE_SIZE and stored in the variable queueSize :

/* * The default buffer size. */
public static final int DEFAULT_QUEUE_SIZE = 256;
int queueSize = DEFAULT_QUEUE_SIZE;

The queue is instantiated as an ArrayBlockingQueue :

blockingQueue = new ArrayBlockingQueue<E>(queueSize);

If queueSize is set too large, the JVM may run out of memory (OOM) because the queue holds references to all pending events.

The discardingThreshold determines when events of level TRACE, DEBUG, and INFO are dropped to protect the queue. Its default value is one‑fifth of queueSize :

static final int UNDEFINED = -1;
int discardingThreshold = UNDEFINED;
if (discardingThreshold == UNDEFINED)
    discardingThreshold = queueSize / 5;

The threshold is applied in append :

@Override
protected void append(E eventObject) {
    if (isQueueBelowDiscardingThreshold() && isDiscardable(eventObject)) {
        return;
    }
    preprocess(eventObject);
    put(eventObject);
}
private boolean isQueueBelowDiscardingThreshold() {
    return (blockingQueue.remainingCapacity() < discardingThreshold);
}

Discardable events are identified by their level:

/* * Events of level TRACE, DEBUG and INFO are deemed to be discardable. */
protected boolean isDiscardable(ILoggingEvent event) {
    Level level = event.getLevel();
    return level.toInt() <= Level.INFO_INT;
}

When the queue is full, put either offers the event without blocking (if neverBlock is true) or blocks until space becomes available:

private void put(E eventObject) {
    if (neverBlock) {
        blockingQueue.offer(eventObject);
    } else {
        putUninterruptibly(eventObject);
    }
}
private void putUninterruptibly(E eventObject) {
    boolean interrupted = false;
    try {
        while (true) {
            try {
                blockingQueue.put(eventObject);
                break;
            } catch (InterruptedException e) {
                interrupted = true;
            }
        }
    } finally {
        if (interrupted) {
            Thread.currentThread().interrupt();
        }
    }
}

The flag neverBlock defaults to false :

boolean neverBlock = false;

Consequently, when the queue reaches the discardingThreshold or becomes full, the appender may block, causing performance degradation, or it may drop low‑level events, leading to log loss.

Configuration recommendations :

To avoid OOM, keep queueSize reasonable and monitor memory usage.

To prevent unwanted log loss, set discardingThreshold to 0 (or a very low value) so that only the queue‑full condition triggers discarding.

If occasional loss is acceptable, enable neverBlock = true to make the appender never block, but be aware that this may drop events when the queue is full.

Increase queueSize if high throughput is required and memory permits.

Following these guidelines helps mitigate the three common pitfalls of AsyncAppender: out‑of‑memory errors, loss of TRACE/DEBUG/INFO logs, and blocking behavior.

loggingLogbackoomBlockingQueueAsyncAppender
Cognitive Technology Team
Written by

Cognitive Technology Team

Cognitive Technology Team regularly delivers the latest IT news, original content, programming tutorials and experience sharing, with daily perks awaiting you.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.