(Synchronous Request-Reply with JMS Considered Harmful)

Our previous look at messaging software (e.g., IBM® WebSphere® MQ and TIBCO Enterprise Message Service™) dispelled the supposed benefits of fire-and-forget messaging. This time we are going to examine the delayed failure problem. It occurs when a synchronous request-reply (A.K.A. in-out or out-in) message exchange pattern is used with messaging software.

In a synchronous request-reply scenario, the client sends a request message to a server and waits for a response. The server receives the request and replies with an appropriate response, which is received by the client. These types of scenario create a temporal coupling between the client and the server; specifically, the server must be running and able to respond when the client makes the request, otherwise the request will fail.

With a connection-based protocol like HTTP, the request will fail immediately if the server is not available. With connectionless messaging systems, like JMS, the client’s request does not fail immediately. Instead the message waits in a queue in the unlikely hope that the server will become available before the message expires. This difference between immediate connection failure and message time-out failure results in inefficiencies: the delayed failure problem.

For user-facing systems, the efficiency difference is obvious. Instead of being able to immediately invoke the appropriate error processing and move onto other work while they wait for the server to be restored, the user must needlessly wait for the delayed failure. For non-user-facing systems, message-based synchronous request-reply is also very inefficient. The client holds onto resources (such as memory, IO connections and so on) while it waits for a response. The sooner the client’s request fails, the sooner the client can release these resources and process other work.

Do you need help designing your services or integration layer to avoid common pitfalls like this one? Contact our services team and we can start discussing how you can improve and increase the robustness of your integration layer today.

One of the main features of messaging systems like JMS is that they provide temporal decoupling between the sender and the receiver. But this very feature is a disadvantage when the sender and the receiver already have temporal coupling in the form of a synchronous request-reply as it merely serves to provide a decoupling of errors during a server failure.

Instead, messaging systems should be reserved for interactions where the sender and receiver are already decoupled from each other. This is the case for asynchronous request-reply interactions, where the temporal decoupling provided by the messaging software can greatly increase the robustness of the interactions.