BooblikClient

Diagram

BooblikClient

The low-level, blocking, single-socket client interface. BooblikClient acts as a thin wrapper around a SocketChannel, providing synchronous methods to send metadata, produce records, and fetch data BooblikClient.kt:24-88. It is designed to be "dumb"—it performs no bookkeeping or request queuing itself, leaving that responsibility to higher-level abstractions.

Pipelined Requests and Correlation IDs

Because the broker is guaranteed to answer requests in the exact order they were received, the client can support pipelining. Each request is assigned a unique correlationId via an AtomicInteger BooblikConnection.kt:71. When a response arrives, the client uses a ConcurrentLinkedQueue of Pending objects to match the response back to the original caller BooblikConnection.kt:60-70. If the broker responds out of order, the client detects the mismatch and fails loudly to prevent delivering data to the wrong caller BooblikConnection.kt:192-195.

BooblikConnection

The coroutine-based implementation of a pipelined connection. It manages two long-running jobs: a writer that drains an outbound channel to the socket and a reader that continuously parses incoming frames BooblikConnection.kt:74-100. This architecture ensures that multiple coroutines can concurrently call produce or fetch without interleaving bytes on the wire, as all writes are serialized through a single coroutine BooblikConnection.kt:40-47.

AckPolicy and Response Behavior

The AckPolicy determines whether a producer waits for a response from the broker BooblikClient.kt:44.

Fetch Long-Polling and maxWaitMillis

The fetch request supports long-polling via the maxWaitMillis parameter BooblikClient.kt:57. If the broker has no data, it can "hold" the request for up to the specified duration. While a request is held, it occupies the connection, meaning subsequent requests on that same connection are blocked LongFetchTest.kt:117-118. A record arriving at the broker during this wait period will wake the fetch immediately LongFetchTest.kt:52-70.

Conformance Testing Scenarios

The conformance client verifies the protocol implementation against specific requirements Main.kt:37-80. Key checks include:

• Keyed Production: Using Partitioner.Fnv1a to select a partition based on a key before sending the produce request Main.kt:158.
• Error Reporting: Ensuring that CORRUPT_REQUEST errors (such as minBytes being larger than maxBytes) are correctly propagated to the client Main.kt:182.

Key files

Behaviour that surprise

• A held fetch request on a BooblikConnection blocks all subsequent requests on that same connection, but does not block requests sent from a different connection LongFetchTest.kt:97-118.
• If a fetch request is cancelled via a timeout, the abandoned read remains on the socket and may consume the response intended for the next read LongFetchTest.kt:37-41.