JMS 1.1 Request Reply Service (V5.2.0 - 5.2.4.0)

Configuring the JMS 1.1 Request Reply Service

You must specify field settings, by using the Admin Console and the GPM.

Use the field definitions in the following table to create a new configuration of the JMS 1.1 Request Reply service, or to set up the configuration provided with the system. Some fields are available in both the Admin Console and in the GPM.

Business Process Example

Example 1

This business process illustrates sending a request and waiting for the time specified in the TIMEOUT (milliseconds) parameter. If no response is received within the timeout parameter, the business process will fail with a request time-out exception. This business process uses a permanent destination rather than a temporary destination to receive a response.

<process name="default">
    <sequence>
         <operation name="JMS11AcquireConnSessionService">
               <participant name="testRegressionsAcquireConnSessionService" />
               <output message="JMS11AcquireConnSessionServiceInputMessage">
                    <assign to="." from="*"></assign>
               </output>
               <input message="inmsg">
                    <assign to="." from="*"></assign>
               </input>
            </operation>
         <operation name="JMSReqRepService">
              <participant name="JMSRequestReplyPermanentDestinationService" />
              <output message="JMSReqRepServiceInputMessage">
                    <assign to="." from="*"></assign>
                    <assign to="BOUNDED_HASHMAP_SIZE">10</assign>
                    <assign to="MSG_TYPE">TextMessage</assign>
                    <assign to="REQUEST_REPLY_EXPECTED_REPLIES">1</assign>
                    <assign to="REQUEST_REPLY_RECIEVE">ReplyDestination</assign>
                    <assign to="REQUEST_REPLY_SEND">RequestDestination</assign>
                    <assign to="REQUEST_REPLY_SEND_TYPE">QUEUE</assign>
                    <assign to="REQUESTER_TYPE">Permanent Destination</assign>
                    <assign to="RR_CONC_CONSUMERS">1</assign>
                    <assign to="TIMEOUT">30000</assign>
                </output>
                  <input message="inmsg">
                    <assign to="." from="*"></assign>
                  </input>
            </operation>
         <operation name="JMS11ReleaseConnSessionService">
               <participant name="testRegressionsReleaseConnSessionService" />
               <output message="JMS11ReleaseConnSessionServiceInputMessage">
                    <assign to="." from="*"></assign>
                    <assign to="RELEASE_ACTION">NONE</assign>
                </output>
                <input message="inmsg">
                     <assign to="." from="*"></assign>
                  </input>
            </operation>
      </sequence> 
</process>

Example 2

This business process uses a temporary destination rather than a permanent destination to receive a response.

<process name="default">
  <sequence>
    <operation name="JMS11AcquireConnSessionService">
      <participant name="testRegressionsAcquireConnSessionService"/>
      <output message="JMS11AcquireConnSessionServiceInputMessage">
        <assign to="." from="*"></assign>
      </output>
      <input message="inmsg">
        <assign to="." from="*"></assign>
      </input>
    </operation>
    <operation name="JMSReqRepService">
      <participant name="JMSRequestReplyTemporaryDestination"/>
      <output message="JMSReqRepServiceInputMessage">
        <assign to="." from="*"></assign>
        <assign to="MSG_TYPE">TextMessage</assign>
        <assign to="REQUEST_REPLY_SEND">RequestDestination</assign>
        <assign to="REQUEST_REPLY_SEND_TYPE">QUEUE</assign>
        <assign to="REQUESTER_TYPE">Temporary Destination</assign>
      </output>
      <input message="inmsg">
        <assign to="." from="*"></assign>
      </input>
    </operation>
    <operation name="JMS11ReleaseConnSessionService">
      <participant name="testRegressionsReleaseConnSessionService"/>
      <output message="JMS11ReleaseConnSessionServiceInputMessage">
        <assign to="." from="*"></assign>
        <assign to="RELEASE_ACTION">NONE</assign>
      </output>
      <input message="inmsg">
        <assign to="." from="*"></assign>
      </input>
    </operation>
  </sequence> 
</process>

Frequently Asked Questions

What is the difference between PERMANENT and TEMPORARY DESTINATION mode?

TEMPORARY DESTINATION

If the JMS API specifies that the Topic or Queue Requestor is used for a request reply, the message is sent to the request/send destination specified in the service. A temporary destination is created for each message sent and is set in the JMS Reply To header of the sent message. A third-party consumer can receive this message and reply back at the temporary destination specified in the reply to header. As soon as the reply is received on this temporary destination, the JMS 1.1 Request Reply flow is marked as complete.

PERMANENT DESTINATION

For the permanent destination mode, the customer provides a receive/reply destination along with the send/request destination. A message is sent to the request destination but instead of setting a temporary destination in the reply to header, the reply/receive destination is specified in the header. A unique correlation id is set in the message header to ensure that we are able to match a request to a response. Additionally, an async receiver is started at the reply/receive destination that collects the replies.

How do I stop the async receiver started in PERMANENT DESTINATION mode by JMS 1.1 Request Reply service?

An async receiver starts listening on the reply destination assigned in the JMS 1.1 Request Reply service as soon as the first request/message is sent. It continues to remain active until manually shutdown. The async receiver can also be stopped by using the JMX or using the JMS 1.1 Release Connection and Session service. The pools span the Async Receiver instances, so shutting down a given Async Receiver only releases the resources back to the pool. The pool to a large degree has its own life cycle that is independent of a given adapter. Thus, to shut down the pool you have to do it explicitly.

The following is an example of the JMS 1.1 Release Connection And Session workflow:

Start > JMS 1.1 Release Connection And Session Service > Stop

The async receiver in the drop down has a format of replyDestination_URL_numberOfConccurentConsumers_BoundedHashMapSize_uniqueID. There is a chance that customer might have created different receivers to the same destination but with different number of concurrent Consumers and different bounded hash map size.

When should I stop the async receiver started in PERMANENT DESTINATION mode by JMS 1.1 Request Reply service?

Why am I seeing more than one async receiver in the PERMANENT DESTINATION mode?

If you fail to shut down the async receiver before changing the BOUNDED HASH MAP LIMIT, REPLY DESTINATION, or the CONCURRENT CONSUMERS parameters, you will see multiple instances of the async receiver. The request reply might fail as more than one receiver is listening to the reply destination. You must shut down the multiplexer before editing any of the parameters.

You can use the JMX to list the number of multiplexers and check if more than one multiplexer is listed against the same destination. Additionally, the multiplexers can be listed using the JMS 1.1 Release Connection and Session service by using the drop down of RR_LIST parameter.

Do I need to specify the correlation id when using JMS 1.1 Request Reply service?

The Correlation Id is not used in the TEMPORARY DESTINATION mode. If you are using the PERMANENT DESTINATION mode, the correlation id is used to uniquely match a request to a reply. You need to have a unique correlation id for every message sent using Request Reply. Unless customers have a unique mechanism to ensure that they will be able to set a unique correlation id for every request this field should be left blank as a unique correlation id is automatically generated in code and set. If the customer provides own correlation id the default one is overridden.

How is a response to a request sent using JMS 1.1 Request Reply service?

For TEMPORARY DESTINATION, the reply should be sent to the destination specified in the reply to header of the received message.

For PERMANENT DESTINATION, the reply should be sent to the destination specified in the reply to header of the received message. The correlation id to the reply should be set to the same as the correlation id of the received/request message.

What happens if I get a message after the received time-out in the PERMANENT DESTINATION mode?

If you are using the PERMANENT DESTINATION mode, the async receiver remains active, unless it is shut down manually. If you receive more replies than was specified in the number of replies, or if a reply is received after the time out of a request, the replies are not lost. To ensure that none of these messages are lost, you can set a property called ERROR_QUEUE as a message header in the reply. Specify the destination where you want these replies to be redirected in case this reply is received after a time-out or if it is more than the number of replies that were expected.

What happens when the JMS provider goes down?

If you are using the PERMANENT DESTINATION mode, there is always an async receiver listening against the reply/receive queue waiting for messages. If the JMS provider goes down, this async receiver executes the retry logic to reconnect itself and the JMS provider will come back. The number of retries and the amount of time between each retry is defined in the jms11.properties file.

What is the difference between disabling the Async Receive Service and stopping the Async Receive/shutting down the pool using the JMX or the Release Connection and Session component?

Shutting down a given async receiver only releases resources back to the pool. The pool to a large degree has its own life cycle that is independent of a given adapter. Thus to shut down the pool you have to do it explicitly.