Messages published via publishAndWait


Suppose, I have a durable subscriber in UM but the consumer is not active at the moment.

What happens to messages published to UM from within the Integration Server using the service pub.publish:publishAndWait?

The caller (the IS service) gets a timeout but what happens to the message in UM? Does it get discarded? Or does it get processed when the cosumer becomes active?


If a timeout occurs, then the original message will still be picked up and processed by the subscriber. But its response will obviously get lost as the publisher is no longer waiting for it.

Jonathan, thank you for the quick response!

It’s clear to me that the sender will not receive the response. But your remark raises another question: Why would the response get discarded in UM? How is it received in UM? Is there a (durable?) subscriber (named object) for it? How does UM know that the message is to be discarded?

The response is returned through a temp queue that automatically gets removed when the IS-UM session is closed. Any responses that were not picked up by waiting publishers will stay in that temp queue and then are discarded when it is removed.

Jonathan, thanks again.

One bit is missing for me to undestand how it works. Who creates the temp queue? If it’s the initial sender how can the responder send a response (because by the time the response is sent the initial sender and hence the queue does not exist anymore)?

If the queue is created by the responder then how would the sender know where to pick up the response?

Thank you for your patience.

The approach is slightly different for JMS or native pub-sub. But generally, each IS-UM connection will establish a temp queue for such response messages when the connection is enabled. So the temp queue will exist for as long as the connection is active.
When the publisher service calls publishAndWait (or sendAndWait), IS automatically includes the name of the temp queue in the reply-to header. That way, the subscribing IS knows where to send the response to when reply is called.

OK, now I’ve got it. Thank you again!

Jonathan, one thing is still not quite clear to me.

Does this mean that all the responses that were not picked up are held in that temp queue? Will it not result in the queue growing without limit? Which may lead to issues with RAM or disc space (depending on storage type)?

Or does this queue get cleared / shrinked from time to time?

I need to double-check that behavior with R&D. The expert who can answer this is not in the office this week, so I hope to get you a response early next week.

That would be great!

Here are more details on how it works.

For JMS (pub.jms:sendAndWait):

  • There is a JMS temp queue per IS JMS connection. If the JMS alias is restarted or the IS restarted, then this queue is recreated and any messages in it are discarded.
  • Request messages will always eventually reach the subscriber, regardless of whether the publisher times out.
  • If a reply message comes back after the publisher has timed out, then the behavior depends on the “Enable Request-Reply Listener for Temporary Queue” setting of the IS JMS alias.
    • If checked, then IS will consume the message from the temp queue and discard it if there is no waiting publisher
    • If not checked, then it will stay on the temp queue until the queue is recreated due to connection or IS restart (see above)

For webMethods Messaging (pub.publish:publishAndWait):

  • There is a request/reply channel per IS messaging connection. This channel is not recreated on restarts.
  • Request messages will always eventually reach the subscriber, regardless of whether the publisher times out.
  • For reply messages, IS will consume the reply message from the req/rep channel and discard it if there is no waiting publisher

Hope this helps.

1 Like

Jonathan, thank you very much for the very detailed and clear explanation and for not forgetting this.