JMS event gateway experiences

 

In one of the recent project I had to consume a JMS message from the publisher and send to the JMS queue for further processing. I call it a intermediate system. The JMS subscriber was the easiest part to implement using the in-built JMS gateway. I just needed to create a new event gateway instance and I was already a subscriber for the messages.

Moving on the next step, the messages needed to be collected and fed into another JMS system, this time a JMS queue. I will not go into too much details but would say I had implemented end-to-end system in ColdFusion. There are a few things that I would like to talk about here.

• The asynchronous nature of JMS needs to be implemented in the intermediate system and the messages delivery had to be guaranteed. The biggest issue that I was up against is to maintain the connectivity with the systems. The subscriber part was ok as it will be taken care of by the event gateway wherein a loss of connectivity with the publisher will not result in any loss of messages as all such messages will be queued before its acknowledged by the subscriber(event gateway in our case). The only issue I need to take care of was if the message was received my the subscriber it has to be delivered to the JMS queue.
• In case of a failure between the intermediate system and the queue happens it has to be made sure that the message is not lost and is delivered after the connection is restored. In such a case the approach that I implemented was to queue up all the incoming messages and run a separate thread that will endlessly try to restore the connection. All messages received from the gateway are stalled (put to sleep).Once the connection to the queue is restored, all the queued messages are delivered. I know this method has a lot of limitation as if the queue size grows beyond a certain limit it can crash. But currently we feel that the outage will be controlled.
• In an ideal scenario, we would like to stop the event gateway instance if the connection to the queue is lost so that there is no message received from the publisher. I am still working out a way to accomplish that.
• For unit testing the intermediate system it was required to manually terminate the connection with the queue and see how the system works. To accomplish that I used a neat little Solaris utility: tcpdrop. I am not sure about such a utility for Windows. You just need to provide the endpoints of the connection along with the ports and you can drop any established TCP connection. I simulated the production scenario of lost connectivity using TcpDrop and all scenario's worked as per plan.

If anyone has a better idea to implement such a system, I would be happy to hear. If anyone is interested in the implementation, I would be happy to share.