What causes "Invalid receive (size = ${receiveSize})" in apache/kafka?

Confirm the connecting client speaks the Kafka protocol and targets the correct listener (PLAINTEXT vs SSL vs SASL_SSL).

apache/kafka · error · InvalidReceiveException

Invalid receive (size = ${receiveSize})

Error message

Invalid receive (size = ${receiveSize})

What it means

Thrown by NetworkReceive.readFrom as an InvalidReceiveException when the 4-byte size prefix read from the channel decodes to a negative value. The Kafka wire protocol frames every message as a 4-byte big-endian length N followed by N bytes of payload; a negative N is structurally impossible for a valid Kafka frame and signals a corrupted or non-Kafka byte stream. The guard exists so the broker/client fails fast instead of trying to allocate or interpret garbage.

Source

Thrown at clients/src/main/java/org/apache/kafka/common/network/NetworkReceive.java:93

    }

    @Override
    public boolean complete() {
        return !size.hasRemaining() && buffer != null && !buffer.hasRemaining();
    }

    public long readFrom(ScatteringByteChannel channel) throws IOException {
        int read = 0;
        if (size.hasRemaining()) {
            int bytesRead = channel.read(size);
            if (bytesRead < 0)
                throw new EOFException();
            read += bytesRead;
            if (!size.hasRemaining()) {
                size.rewind();
                int receiveSize = size.getInt();
                if (receiveSize < 0)
                    throw new InvalidReceiveException("Invalid receive (size = " + receiveSize + ")");
                if (maxSize != UNLIMITED && receiveSize > maxSize)
                    throw new InvalidReceiveException("Invalid receive (size = " + receiveSize + " larger than " + maxSize + ")");
                requestedBufferSize = receiveSize; // may be 0 for some payloads (SASL)
                if (receiveSize == 0) {
                    buffer = EMPTY_BUFFER;
                }
            }
        }
        if (buffer == null && requestedBufferSize != -1) { // we know the size we want but haven't been able to allocate it yet
            buffer = memoryPool.tryAllocate(requestedBufferSize);
            if (buffer == null)
                log.trace("Broker low on memory - could not allocate buffer of size {} for source {}", requestedBufferSize, source);
        }
        if (buffer != null) {
            int bytesRead = channel.read(buffer);
            if (bytesRead < 0)
                throw new EOFException();
            read += bytesRead;

View on GitHub (pinned to c31c9215e1)

Solutions

Confirm the connecting client speaks the Kafka protocol and targets the correct listener (PLAINTEXT vs SSL vs SASL_SSL).
Stop any HTTP/Telnet/health-check probes hitting the Kafka port; use a Kafka-aware tool (kafka-broker-api-versions, kcat) to test.
If SSL is configured, verify the client is actually performing a TLS handshake rather than writing plaintext.

Example fix

// before: plaintext probe against an SSL listener
$ nc broker 9092  # sends raw bytes -> negative size prefix

// after: test with the correct protocol
$ kafka-broker-api-versions --bootstrap-server broker:9092 --command-config client-ssl.properties

Defensive patterns

Strategy: try-catch

Try / catch

try {
    long read = networkReceive.readFrom(channel);
} catch (InvalidReceiveException e) {
    // Peer sent a negative size: protocol violation. Drop the channel.
    log.warn("Invalid receive from {}: closing channel", networkReceive.source(), e);
    Utils.closeQuietly(channel, "channel");
    disconnect(networkReceive.source());
} catch (EOFException | IOException e) {
    handleDisconnect(networkReceive.source(), e);
}

Prevention

Only connect NetworkReceive/Selector to trusted Kafka brokers; a negative size prefix is always malformed or hostile.
Keep client and broker versions aligned so the size-delimited framing is mutually understood.
Treat InvalidReceiveException as a connection-fatal event: never retry on the same channel.
Monitor this exception as a signal of corruption, version skew, or man-in-the-middle tampering.

When it happens

Trigger: A client (Kafka or otherwise) connects to a Kafka port and sends bytes whose first 4 bytes decode to a negative int; e.g. a plain HTTP/Telnet/redis-cli probe against the Kafka port, a partially-truncated SSL handshake sent as plaintext, or a binary protocol mismatch (pointing a non-Kafka client at the broker).

Common situations: Running 'curl http://broker:9092' or 'nc broker 9092' to test connectivity; a load balancer/proxy doing a TCP health check that sends junk; sending plaintext to a SASL_SSL/SSL listener (or vice versa); mixed-up container port mappings exposing a different service on 9092.

Related errors

AI-assisted analysis of apache/kafka@c31c9215e1 (2026-08-03). Data as JSON: /data/errors/229595e08e973e5a.json. Report an issue: GitHub.