Kbase P97921: Adapter for SonicMQ: Fault Tolerance Sample Code
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
14/02/2006 |
|
Status: Unverified
GOAL:
Fault Tolerant Sample Code for Adapter for SonicMQ connections
GOAL:
How to code fault tolerance for the connections between the 4GL client, Adapter for SonicMQ, and SonicMQ Broker
GOAL:
How to implement fault tolerant connection logic in the Adapter for SonicMQ environment
GOAL:
How to trap connection loss to SonicMQ?
GOAL:
How to trap connection loss to the Adapter for SonicMQ?
FACT(s) (Environment):
Progress 9.1x
OpenEdge 10.x
SonicMQ
FIX:
In the Adapter for SonicMQ Environment, there are two connections that need to be considered when implementing fault tolerant connection logic.
1. The connection between the 4GL Client and the Adapter for SonicMQ
2. The connection between the Adapter for SonicMQ and the SonicMQ Broker.
Both of these connection are created by the 4GL-JMS API call beginSession.
Depending on when the Connection loss is detected, the 4GL application must be coded to handle two different types of run-time conditions:
1. Synchronous run-time conditions:
A run-time condition is reported synchronously if it occurs and is detected while the 4GL application is executing a 4GL-JMS API call.
For example, a Synchronous run-time condition will occur if 4GL-JMS API call beginSession is invoked while the Adapter for SonicMQ or SonicMQ Broker components are off-line or unavailable.
Synchronous run-time conditions can be handled with standard 4GL error handling techniques such as a NO-ERROR phrase or an ON ERROR block.
2. Asynchronous run-time conditions:
A run-time condition is reported asynchronously when it raised by the asynchronous error reporting system of the JMS server or by the 4GL?JMS mechanism that delivers messages asynchronously from the Adapter for SonicMQ to the 4GL client.
For Example, an Asynchronous run-time condition will occur if the 4GL application is in a wait-for state (waiting for message delivery) and the communication between the Adapter for SonicMQ and the SonicMQ broker is interrupted.
Asynchronous run-time conditions can be handled from a 4GL-JMS message consumer object that is passed to the setErrorHandler procedure in the session object.
Below are two sample procedures that are coded to handle Synchronous and Asynchronous connection failures.
The first is a producing application that publishes messages through the Adapter for SonicMQ to a Queue destination on the SonicMQ Broker.
The second is a consuming application that subscribes to the same topic and receives messages that are published by the producer.
To demonstrate the reconnect logic:
1. Run the consumer.
2. Run the producer.
3. Shutdown the broker and restart
4. Wait for connections to re-established from above step and then shutdown the adapter and restart
Notice both programs will catch the connection loss and the reconnect.