bookkeeper icon indicating copy to clipboard operation
bookkeeper copied to clipboard

Add cancellation support for async add interface with pre-IO check

Open zhaizhibo opened this issue 5 months ago • 3 comments

FEATURE REQUEST

Currently, the async add operation in Bookie (e.g., asyncAddEntry) lacks a mechanism to fast-fail if the request is cancelled before actual I/O (e.g., writeAndFlush). This can lead to unnecessary resource consumption (e.g., thread pool, queue, direct mem) for cancelled requests, especially in high-throughput scenarios where clients may cancel pending writes due to timeouts or application logic.

zhaizhibo avatar Jul 30 '25 02:07 zhaizhibo

org.apache.bookkeeper.client.LedgerHandle#asyncAddEntry maybe like this: public void asyncAddEntry(ByteBuf data, final AddCallback cb, final Object ctx, final Supplier cancelled) { xxx }

zhaizhibo avatar Jul 30 '25 02:07 zhaizhibo

I suggest describing the scenario more clearly, including specific scenarios and metrics. Or you could submit a BP-* to initiate this initiative.

I personally think your requirements are overly complex and may not fit into BookKeeper's current ecosystem.

StevenLuMT avatar Jul 31 '25 01:07 StevenLuMT

I suggest describing the scenario more clearly, including specific scenarios and metrics. Or you could submit a BP-* to initiate this initiative.

I personally think your requirements are overly complex and may not fit into BookKeeper's current ecosystem.

When implementing Kafka on Pulsar, timeout is configured per request, not per broker. Kafka uses timewheel for timeouts, which doesn't align with Pulsar and BookKeeper client. During stress testing, we observed many write requests queued in thread pools (due to BK server bottlenecks). When KOP cancels these writes, the cancellation doesn't propagate to BK client. Without this, we cannot fast failure in this case. 

zhaizhibo avatar Jul 31 '25 11:07 zhaizhibo