Search before asking
Fluss version
main (development)
Please describe the bug 馃悶
When the Fluss Sender encounters an OutOfMemoryError or another fatal synchronous error while encoding or sending a write RPC, some write batches can become permanently stuck.
The failure flow is:
- The batches have already been drained from the accumulator and registered in
Sender.inFlightBatches.
- The RPC fails before it is actually sent to the server.
- No response future or completion callback is available to handle these batches.
- The batches are neither completed, re-enqueued, nor deallocated, so they continue holding writer-buffer memory indefinitely.
- The writer buffer is eventually exhausted and subsequent writes block, while the Sender still appears to be running.
With idempotent writes, later batches may also receive OUT_OF_ORDER_SEQUENCE_EXCEPTION because an earlier sequence was never delivered or re-enqueued.
Root cause
Sender.sendWriteData drains ready batches from the accumulator.
- It adds all drained batches to
Sender.inFlightBatches before calling sendWriteRequests.
ServerConnection.doSend registers the RPC request before encoding it.
- The encoding cleanup catches only
Exception. A fatal Error, such as OutOfMemoryError, escapes synchronously from gateway.putKv(request) or gateway.produceLog(request).
- Because the gateway call throws before returning a
CompletableFuture, the Sender's whenComplete callback is never registered.
- The outer Sender loop catches
Throwable, logs it, and continues without completing, re-enqueuing, or deallocating the affected batches.
Expected behavior: every drained batch must either be associated with a completable RPC future, re-enqueued, completed successfully, or failed and deallocated. Fatal errors should fail the writer/task instead of only being logged.
Solution
- Clean up the RPC registration for every synchronous encoding failure.
- Ensure synchronous gateway failures cannot leave Sender batches orphaned.
- Stop the Sender and fail or abort incomplete batches on fatal errors.
- Add tests that inject a fatal encoding/send failure and verify that in-flight entries are removed, futures complete exceptionally, and writer-buffer memory is released.
Are you willing to submit a PR?
Search before asking
Fluss version
main (development)
Please describe the bug 馃悶
When the Fluss Sender encounters an
OutOfMemoryErroror another fatal synchronous error while encoding or sending a write RPC, some write batches can become permanently stuck.The failure flow is:
Sender.inFlightBatches.With idempotent writes, later batches may also receive
OUT_OF_ORDER_SEQUENCE_EXCEPTIONbecause an earlier sequence was never delivered or re-enqueued.Root cause
Sender.sendWriteDatadrains ready batches from the accumulator.Sender.inFlightBatchesbefore callingsendWriteRequests.ServerConnection.doSendregisters the RPC request before encoding it.Exception. A fatalError, such asOutOfMemoryError, escapes synchronously fromgateway.putKv(request)orgateway.produceLog(request).CompletableFuture, the Sender'swhenCompletecallback is never registered.Throwable, logs it, and continues without completing, re-enqueuing, or deallocating the affected batches.Expected behavior: every drained batch must either be associated with a completable RPC future, re-enqueued, completed successfully, or failed and deallocated. Fatal errors should fail the writer/task instead of only being logged.
Solution
Are you willing to submit a PR?