JMS request and reply messaging with cluster bus members
A typical JMS messaging pattern involves a requesting application that sends a message to a JMS queue for processing by a messaging service, for example, a message-driven bean.
When the requesting application sends the request message, the message identifies another JMS queue to which the service should send a reply message. After sending the request message, the requesting application either waits for the reply message to arrive, or it reconnects later to retrieve the reply message.
Figure 1. Typical JMS messaging pattern
The request and reply pattern requires the following conditions:
- The requesting application can identify, in the requesting message, where the service must send the reply message.
- The requesting application can consume the reply message from the reply location.
A JMS queue can refer to a service integration bus destination defined on a server bus member or cluster bus member.
- If the bus member is a server (which can have only one messaging engine), or a cluster with a single messaging engine, a JMS queue
identifies a single service integration bus queue point.
- If the bus member is a cluster with multiple messaging engines (typically, to provide workload sharing or scalability), a JMS queue identifies multiple queue points; one on each messaging engine in the bus member.
Figure 2. A service integration bus queue destination defined to an application server bus member
The following behavior occurs by default:
- The queue point that an application sends messages to, or receives messages from, is determined by the messaging system.
- During its lifetime, a consumer, in this case a JMS message consumer, consumes from only one queue point.
This request and reply behavior allows a reply message to be sent to a different queue point from the one on which the requester is waiting for it. This can result in the reply message not being received.
Figure 3. A service integration bus queue destination defined to a cluster bus member with two messaging engines
To overcome this situation, there are various options when you configure the service integration bus system or the JMS applications:
- Use a temporary queue as the reply
queue.
- Use a scoped service integration bus alias destination to restrict messages to a single queue point.
- Restrict reply messages to the queue
point that is local to the requesting application.
- Configure the requester to consume messages from all queue points simultaneously.
Consider the advantages and disadvantages of each option and the requirements of the application, before you choose an approach.
Summary
Use the simplest solution that satisfies the requirements of the request/reply scenario. For example:
- If reply messages are required only while the requesting application is initially connected, use non-persistent messages and temporary
queues. Also consider setting a timeToLive of the initial request message, if the requesting application will wait
for a reply for only a finite time.
- If a single queue point (and its messaging engine) can handle all the reply message traffic for the requesting applications, but a cluster bus member with multiple messaging engines is required for other messaging traffic (for example, the request messages), use a service integration bus alias destination to scope the messages to that single queue point.
If necessary, we can combine these options to achieve the solution that best satisfies the requirements of the application and has the best performance and scalability.
For example, if requesting applications typically receive their reply messages during the initial connection but under certain rare conditions (for example, a failure) they have to reconnect to receive the reply, the following approach might be suitable:
- Enable the scopeToLocalQP option of the JMS
queue, and allow the requesting application to connect to any of the messaging engines in the cluster bus member (that is, target the JMS
connection factory at the bus member). This allows the connections to be workload balanced but restricts reply messages to the local queue point. The result is that reply messages can be found while
using the same connection to receive the reply that was used to send the request.
- When re-connecting after a failure, enable the Message gathering option on the JMS queue so that the reply message can be received from wherever it is held.
This approach enables dynamic workload balancing of the requesting applications and minimizes the performance implications of message gathering by reducing its use to failure scenarios.
Subtopics
- Use a temporary queue as a reply queue
JMS can create a temporary queue dynamically for use as a reply queue. We can use this to ensure that a reply message is sent to the appropriate queue point for a cluster bus member. - Use a scoped service integration bus alias destination to restrict messages to a single queue point
We can use a service integration bus alias destination to target a service integration bus queue that has multiple queue points. We can do this to ensure that a reply message is sent to the appropriate queue point for a cluster bus member. - Restricting reply messages to the queue point that is local to the requesting application
When a JMS queue identifies a service integration bus queue as the reply queue, and that service integration bus queue has multiple queue points, we can configure a JMS queue to restrict the messages to the queue point that is local to the application that referenced the JMS queue. You do this to ensure that a reply message is sent to the appropriate queue point for a cluster bus member. - Configure the requester to consume messages from all queue points simultaneously
By default, a JMS message consumer consumes from only one queue point for the lifetime of the message consumer. If the reply queue has more than one queue point, unless the reply message is restricted to one particular queue point, the consumer might not be consuming from the queue point to which the reply is sent, and might not receive the reply message.
Related concepts