nathanmarz/storm · error · RuntimeException

Client is being closed, and does not take requests any more

Error message

Client is being closed, and does not take requests any more

What it means

Netty Client.send enqueues messages to a transport queue, but once the client is shutting down (being_closed flag set), it refuses new work. Calling send after close() was initiated throws this RuntimeException at Client.java:126, protecting against writes to a closing connection.

Solutions

Stop sending messages before initiating client.close(); track the closed state in application code.
Guard sends with a shutdown latch: set your own flag before close() and skip sends afterwards.
Recreate the Client if you need to send after a previous one was closed (it is not restartable).
Catch RuntimeException around send during shutdown windows and drop/retry via a live client.

Example fix

// before
client.close();
client.send(task, tupleBytes); // throws
// after
client.send(task, tupleBytes);
client.close();

Defensive patterns

Strategy: try-catch

Validate before calling

if (clientClosed.get()) { /* skip or recreate client */ }

Try / catch

try {
    client.send(task, message);
} catch (RuntimeException e) {
    if (e.getMessage().contains("does not take requests any more")) {
        // recreate client or drop message during shutdown
    } else {
        throw e;
    }
}

Prevention

Close clients only after all emitting threads have stopped.
Track shutdown state in application code before calling close().
Coordinate close() with worker shutdown hooks and topology lifecycle.

When it happens

Trigger: Calling client.send(task, message) after client.close() has been called, or concurrently while close() is in progress; a supervisor/worker shutdown path racing with topology message dispatch.

Common situations: Worker shutdown while bolts still try to emit tuples; custom code holding a Client reference past connection teardown; storm shutdown hooks racing with in-flight send loops.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

AI-assisted analysis of nathanmarz/storm@cdb116e942 (2026-09-12). Data as JSON: /api/errors/19e34cfbacd41c02. Report an issue: GitHub.

Appendix: source

Thrown at storm-netty/src/jvm/backtype/storm/messaging/netty/Client.java:126

    /**
     * # of milliseconds to wait per exponential back-off policy
     */
    private int getSleepTimeMs()
    {
        int backoff = 1 << retries.get();
        int sleepMs = base_sleep_ms * Math.max(1, random.nextInt(backoff));
        if ( sleepMs > max_sleep_ms )
            sleepMs = max_sleep_ms;
        return sleepMs;
    }

    /**
     * Enqueue a task message to be sent to server
     */
    public void send(int task, byte[] message) {
        //throw exception if the client is being closed
        if (being_closed.get()) {
            throw new RuntimeException("Client is being closed, and does not take requests any more");
        }

        try {
            message_queue.put(new TaskMessage(task, message));
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    /**
     * Take all enqueued messages from queue
     * @return
     * @throws InterruptedException
     */
    MessageBatch takeMessages()  throws InterruptedException {
        //1st message
        MessageBatch batch = new MessageBatch(buffer_size);
        Object msg = message_queue.take();

View on GitHub (pinned to cdb116e942)