[client] Support bounded write delivery (delivery timeout)
- Dominant language
- Java
- Stars
- 2.1k
- Forks
- 625
- Avg merge
- 3d 14h
- Merged PRs (30d)
- 97
Description
### Search before asking
- [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.
### Description
Java client write delivery is currently bounded only by `client.writer.retries` (default `Integer.MAX_VALUE`) and is therefore effectively unbounded. `client.writer.batch-timeout` is only a linger, while `client.request-timeout` applies to a single RPC attempt.
A record may remain in the accumulator and retry loop indefinitely, for example when the leader is unavailable. Timing out or abandoning the returned future does not remove it, so it may still be written later.
Add a Kafka `delivery.timeout.ms`-style bound that expires unsent batches, stops retries after the deadline, and completes the corresponding futures exceptionally. For an already in-flight request, timeout means the write result is unknown.
This is the Java client counterpart of #3861.
### Willingness to contribute
- [ ] I'm willing to submit a PR!
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the Java client’s accumulator and retry loop, then trace how client.writer.retries, client.writer.batch-timeout, and client.request-timeout affect returned futures. Compare the intended behavior with the Kafka delivery.timeout.ms model and counterpart issue #3861. Done means unsent batches expire, retries stop at the deadline, and corresponding futures complete exceptionally while in-flight results are identified as unknown.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100