Add cancellation support for async add interface with pre-IO check
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.
org.apache.bookkeeper.client.LedgerHandle#asyncAddEntry
maybe like this:
public void asyncAddEntry(ByteBuf data, final AddCallback cb, final Object ctx, final Supplier cancelled) { xxx }
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.
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.