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.