LMAX-Exchange/disruptor · error · IllegalArgumentException

The event handler {} is not processing events.

Error message

The event handler {} is not processing events.

What it means

Thrown by ConsumerRepository.getEventProcessorFor when no registered event processor matches the given EventHandlerIdentity (the handler instance). The DSL tracks every handler added via handleEventsWith/handleEventsWithWorkerPool; asking for the processor or sequence of an unregistered handler means the wiring never happened or the wrong instance was passed.

Source

Thrown at src/main/java/com/lmax/disruptor/dsl/ConsumerRepository.java:94

                for (Sequence sequence : sequences)
                {
                    if (cursor > sequence.get())
                    {
                        return true;
                    }
                }
            }
        }

        return false;
    }

    public EventProcessor getEventProcessorFor(final EventHandlerIdentity handlerIdentity)
    {
        final EventProcessorInfo eventprocessorInfo = getEventProcessorInfo(handlerIdentity);
        if (eventprocessorInfo == null)
        {
            throw new IllegalArgumentException("The event handler " + handlerIdentity + " is not processing events.");
        }

        return eventprocessorInfo.getEventProcessor();
    }

    public Sequence getSequenceFor(final EventHandlerIdentity handlerIdentity)
    {
        return getEventProcessorFor(handlerIdentity).getSequence();
    }

    public void unMarkEventProcessorsAsEndOfChain(final Sequence... barrierEventProcessors)
    {
        for (Sequence barrierEventProcessor : barrierEventProcessors)
        {
            getEventProcessorInfo(barrierEventProcessor).markAsUsedInBarrier();
        }
    }

View on GitHub (pinned to c871ca4982)

Solutions

1. Reuse the exact handler instance you registered with handleEventsWith when calling getSequenceFor/after.
2. Store handlers in named fields instead of inline lambdas when you need to query them later.
3. For manually wired processors, keep their Sequence references directly instead of asking the Disruptor.

Example fix

// before
disruptor.handleEventsWith(event -> process(event));
...
Sequence s = disruptor.getSequenceFor(event -> process(event)); // new lambda -> never matches

// after
EventHandler<MyEvent> handler = event -> process(event);
disruptor.handleEventsWith(handler);
Sequence s = disruptor.getSequenceFor(handler);

EventHandler<MyEvent> handler = new MyHandler(); // one instance
disruptor.handleEventsWith(handler);
// later reuse the SAME instance:
Sequence seq = disruptor.getSequenceFor(handler);

static boolean isRegistered(Disruptor<?> d, EventHandler<?> h) {
    try { d.getSequenceFor(h); return true; }
    catch (IllegalArgumentException e) { return false; }
}

try {
    Sequence seq = disruptor.getSequenceFor(handler);
} catch (IllegalArgumentException e) {
    // handler was never registered (or wrong instance) — fix wiring, do not swallow
    throw new IllegalStateException("handler not registered with Disruptor: " + handler, e);
}

When it happens

Trigger: Calling disruptor.getSequenceFor(handler) or after(handler)/handleEventsWith after an unknown handler instance — e.g. passing a new instance (handlers are tracked by identity, not equals), or querying a handler that was never added via the DSL because it was wired manually with a custom EventProcessor.

Common situations: Passing a freshly constructed handler where the registered one lives in a field; lambda handlers (each lambda is a distinct object, so re-specifying the lambda later never matches); mixing DSL wiring with manual RingBuffer/BatchEventProcessor wiring.

Related errors

• bufferSize must not be less than 1
• bufferSize must be a power of 2
• maxBatchSize must be greater than 0
• Rewindable Exception thrown from a non-rewindable event hand
• setDefaultExceptionHandler can not be used after handleExcep

AI-assisted analysis of LMAX-Exchange/disruptor@c871ca4982 (2026-08-14). Data as JSON: /api/errors/e845777d1a56400f. Report an issue: GitHub.