Agreed. I had already thought about that. It should be easy to acknowledge the message when the answer comes back (hence the need for the DONE status even for InOnly exchanges ;) ), though I haven't had time to do it.
Of course, this should be an optional settings, as this may be a bit less efficient (but more reliable of course). Please raise a JIRA and feel free to work on it and attach a patch. We always welcome contributers ;) On 8/24/06, Klaus Alfert <[EMAIL PROTECTED]> wrote:
Hello folks, I am currently testing the jms connectivity of servicemix, in particular with Websphere MQ. After some help of Guillaume it works now. So, my next test is to see what happens when servicemix crashes. My test-setup is simple, one process populates a queue, servicemix reads this queue and writes each message in a second queue, which is consumed by a second process. During this test servicemix is killed and restarted. My test results showed that some times some messages are lost. Looking in the source code reveals that reading from the queue is done with an AUTO_ACKNOWLEDGE, which implies that there is no dependency between doing an (implicit) commit on the queue and successful sending of a message to another JBI endpoint. Apparently, this can result in lost messages if servicemix crashes. I could possibly use the JCAProcessor, but then I need an external transaction manager, which I do not have - at least if I understand the JCA concept correctly. To make things short, I would suggest to extend the servicemix-jms binding component with the (configurable) ability to make the read of an input queue dependent on the successful NMR send. This would add more realiability to servicemix, if needed. Or did I miss something and there is already the possibility to achieve this kind of transacted queue read? Cheers, Klaus. -- View this message in context: http://www.nabble.com/Improving-reliability-of-servicemix-jms-tf2158845.html#a5964588 Sent from the ServiceMix - Dev forum at Nabble.com.
-- Cheers, Guillaume Nodet
