Hi,
When pushing messages to a non-Sonic system from the ESB, is it possible to stop processing messages from the entry endpoint if the non-Sonic system appears to be unavailable?
background: I am building a servicetype which pushes messages onto an AS400 dataqueue. It is possible that that system is unreachable because of network problems or other causes. In such cases I do not want to find all my messages on the RME, but I would rather have my process restarting delivery automatically after the problems have been solved.
If that is not possible, which would be the best alternative approach?
TIA,
Marijn
Hi Marijin,
I had a simliar problem with my project. I was calling a web service that could become unavailable, and I did not want all the messages going to the RME queue.
I created a custom service and implemented a wait/retry capability in the Java code. Basically, if the service receives a RemoteException, It waits for 30 seconds and then retries. The service will retry forever, however I will implement something in the future that will allow an administrator to break out of it.
It works very nicely, as we have had the external web service go down for hours and hours. The ESB will just sit there and wait for the web service to become availalbe again.
We have been running this in produciton for four months now with no problem.
Hope this helps,
Nathan
Hi Nathan,
I was thinking about such an approach, but I do not quite like the idea of "hanging up" the service. Furthermore, if the service is in "unreachable" state and it then gets killed because of a timeout on the stop signal, I will lose a message (I think - need to test that)
Thanks for your thoughts,
Marijn
Marijn
As long as your service does not acknowledge the message then the message will not be lost, i.e. the end of the service method is never reached. And in fact the message will remain on the queue/topic if the containers goes down.
David
David is correct. Even when we had to break out of the service manually, we have never lost the message. The SMC shows that the message is gone, but it does not get lost. In my case, the message re-appeared on the queue when the container restarted.
I'm not sure what you mean by hanging up the service, however if your external system is down, isn't that the behavior you want? In my case, the wait/retry works very well. Let me know your thoughts.
Nathan
Yes, I am happy!
I already figured I could just keep stalling inside the service method, but I wrongly assumed that that would keep the service from responding to stop requests.
Your comments and a bit of testing showed that I can throw an XQServiceException without consuming the message - resulting in a message on the RME, my original message on the entry endpoint and the service nicely responding to the stop request.
Thanks for your efforts!