Request to delay consumer and listener container shutdown to wait for pending reply messages when using Request/Reply Messaging with a fixed name reply queue.

[dldiehl77]

Expected Behavior

When using the Request/Reply Messaging feature, a request message is sent, but before the reply message is received, the application starts a graceful shutdown (think of the case when running in a container orchestration platform and it decides that it wants to stop your container). Would like the consumer and listener container to wait for a reply message -- up to some configurable amount of time (something short, like 30 seconds). We always set an expiration TTL on the request message while calling the template method convertSendAndReceive, so a timeout on that synchronous call is the other possible outcome.

Current Behavior

Right now when the graceful shutdown commences, the consumer and listener container shut down quickly, presumably because there are no messages on the reply queue. The reply message does not yet exist.

Context

Our request messages are the result of customer interaction. They cause processing to happen in a remote location. The reply message is used to indicate successful processing back to a customer. Our orchestration platform periodically decides to stop a container (or one stops when we deploy a new version of software) and those currently executing instances sometimes have in-flight request messages that are awaiting reply messages. When the container stops without receiving the reply message, that message is lost, and we have to report a system error to the customer.

Artem noted on stackoverflow.com a possible workaround using a temporary queue name for each request/reply, but I'd really, really like to stick with fixed named queue to solve this issue.

[artembilan]

Related StackOverflow question: https://stackoverflow.com/questions/79532114/how-to-delay-shut-down-when-using-request-reply-messaging-and-have-consumer-and

[artembilan]

I see a ListenerContainerAware contract which is consulted in the SimpleMessageListenerContainer.
So, we can use that hook to get access into the active state of the listener when we are in stopping phase for the listener container.
This way we may wait for that shutdownTimeout to let those pending replies to arrive during that window.

Feel free to try to contribute that fix or share any other thoughts.

Thanks