At the moment, as part of processing the signals that arrive in response to close calls, the AMQP engine wait to ensure any lingering messages, dispositions enqueued and other state in transit is processed, so last connection and it’s in-memory data structures are cleaned up gracefully.

There are certain signals route (e.g., client-side local shutdown) where this wait can be optimized so that close call may return early. Creating this feature-request to analyze and see close experience in these routes maybe improved.

Refer here #24582 (comment) for various close signal routes, those diagrams are bit old but not outdated.

Changing the state machine’s behavior to improve this edge case needs to be done carefully to make sure it is not causing regressions in common cases (E.g., continuous messaging pumping in Processor), that internally roll connections transparently.

In case of any special use cases where applications do not want to wait for close to return (E.g., application is shutting down, re-starting) so eager termination, the workaround is to invoke close on CompleteableFuture with a timeout that application wants to impose.

// The Client is no longer needed, fire and forget the client close
try {
    CompletableFuture.supplyAsync(() -> {
     // call Client::close.
        return null;
    }).toCompletableFuture().get(5, TimeUnit.SECONDS);
} catch (Exception e) {
    // log(e);
}
// deployment restarts or application creates new Client