IAsyncBatchEventHandler with CancellationToken

[jinghua395]

Hi,

I wonder if there is a plan to add CancellationToken intioi IAsyncBatchEventHandler interface, it could get cancelled when shutdown process? If is it technically possible?

IAsyncBatchEventHandler
ValueTask OnBatch(EventBatch batch, long sequence, CancellationToken cancellationtoken);

[ocoanet]

I think it is a good idea even though it is probably a niche requirement. I suspect that most async handlers are relatively short running and thus do not require cancellation support. I will try to find the proper design for this. Your suggestion is clean and simple but it would be a breaking change, so I might decide to add a dedicated interface.

[ocoanet]

In my view, most event handlers are supposed to be short running and they should process all published events. On shutdown, the Disruptor will wait until published events are processed by all event handlers before halting the handlers.

I do not clearly understand what an event handler could do with the halting CancellationToken. It could cancel the active async task of course, but it would still have to process the event anyway (and the other remaining published events).

@jinghua395 Could you describe your use case so I can better understand the value of exposing the CancellationToken?

Right now, I consider adding a dedicated interface like the following one to expose the CancellationToken to event handlers:

public interface IEventProcessorCancellationTokenAware
{
    void SetCancellationToken(CancellationToken cancellationToken);
}

It is clearly less discoverable than exposing then token in IAsyncBatchEventHandler (for example passing the token in OnStart). But I would like to avoid exposing the token if using it is not a good practice.

[jinghua395]

In general, I would use the cancellation token to cancel the async operation, e.g., network or I/O, (they might not fast operation as CPU workload), then we are not waiting when the disruptor shuts down, or not start expensive async operation when the disruptor is shut down.

I am also thinking we could have a disruptor ShutdownAsync(int timeout), thus we could wait the handler to finish in a graceful manner or brutally shut it down if timeout.