v0.9.3

Oxia Java Client 0.9.3 makes write batching adapt to the server's service rate: each shard now has a bounded window of in-flight write batches, and while the window is exhausted operations keep accumulating into the shard's open batch instead of being flushed as new small requests.

Performance Improvements

• Rate-adaptive write batching with a bounded per-shard in-flight window (#360). Previously the client dispatched every write batch straight onto the shard's write stream, so under load the server received a flood of small requests (~4.5 puts each on a loaded 3-node cluster, despite maxRequestsPerBatch=1000) and the write path was bound by per-shard replication rounds carrying almost no work, while pending operations piled up in an unbounded queue. Now at most maxWriteBatchesInFlight (default 4) batches per shard are outstanding at once, and when the window is exhausted batches grow toward maxRequestsPerBatch. In a loopback insert-only benchmark this raised the average batch size from ~12 to ~1,000 operations per commit (~84× fewer replication rounds), improved write throughput by ~24%, and cut p99.9 write latency from 404 ms to 147 ms. When the server is keeping up, behavior is unchanged: batches stay small and are flushed immediately.

Compatibility

• There are no breaking API changes: code built against 0.9.2 keeps compiling and running.
• Under server saturation, writes are delivered in larger and fewer requests; per-shard submission order is preserved, and the window never stalls other shards or clients sharing the same batcher thread.
• On client close, write batches still held back by a shard's window now fail promptly, consistent with the existing close semantics for open batches.
• Memory for held-back batches remains bounded by the existing maxPendingBytes limit.

Requirements

• Java 17 is required (unchanged).
• No data migration is required.
• No configuration change is required.

Public API Changes

• New OxiaClientBuilder.maxWriteBatchesInFlight(int): the maximum number of write batches that can be in flight to the server for each shard, default 4 (#360).