How does one wait for all event handlers to fully complete processing after shutdown?

Version: 3.3.2

It appears that event handlers are not necessarily finished executing when Disruptor.shutdown() returns. What is the definitive way to detect when all event handlers have finished execution after the disruptor is shutdown?

As a point of illustration, this unit test sometimes prints 0, and sometimes prints 1:

public class ShutdownTest {
    volatile int value = 0;

    @Test
    public void shutdownFailure() throws TimeoutException
    {
        Disruptor<Void> disruptor = new Disruptor<>(() -> null, 8, (ThreadFactory) Thread::new);
        disruptor.handleEventsWith(this::updateValue);
        disruptor.start();
        disruptor.getRingBuffer().publishEvent((m, s) -> {});
        disruptor.shutdown(10, TimeUnit.SECONDS);

        System.out.println(value); // Sometimes prints 0, but if updateValue has completed it would be expected to always be 1.
    }

    private void updateValue(Message message, long sequence, boolean endOfBatch)
    {
        value = 1;
    }
}

What is the correct way of ensuring that “1” is printed, always?

[mikeb01]

It is a source of confusion that I want to fix, but doing it transparently (without API or behaviour change) is tricky and given that it tends to only turn up in unit tests and there is a fairly straight-forward workaround it keeps falling to the bottom of the priority list.

[mattmiller1988]

That’s the primary source of confusion for me, I suppose. In this example, the thread does seem to actually start and handle traffic, but because the shutdown happens so quickly it seems to skip doing the onShutdown method.

The logs from a failed iteration of this test are: Event 1 Start 2 Event 2

That indicates to me that the threads have already started because:

1. The onStart() is being called.
2. The onEvent() is being called.

Despite these two functions being executed, the onShutdown() is never called when the thread is killed. That’s pretty confusing as I would expect after an onStart() you would always see an onShutdown().

This probably won’t ever be an issue in production code because it’s unlikely people would ever start and stop the disruptor so quickly, but it’s a bit of a nuisance in unit testing where you’re more likely to be starting and stopping them in quick succession. As you’ve pointed out, it can be worked around by adding the startup latch and ensuring the startup has finished before the shutdown is initiated.