The uncommenting that I was talking about referred to the code in my example that is
currently commented out for when any exception is caught on sending a message on
connection1. I was attempting to see if cleaning up (i.e. trying to close) the defunct
connection on an exception affected the operation of the second connection (it does seem
to). I think that the example never uses the first connection again after it has detected
any exception.
I know this code is not how you would do it in practice, but I was trying to keep the
sample as tight as possible to demonstrate the problem. Our actual application is more
complex, as it initiates reconnect in a background thread and obtains its sessions from a
session pool but I didn't think this was the cause of the problem that we are
observing.
Is there any chance of getting the fix that Tim is talking about into a 1.0.x release? We
are hoping to offer JBoss Messaging support as part of our application, but with this
problem we cannot as we need some form of high availability. Was it a relatively confined
change that we could patch in ourselves? Would you be able to give us a start and tell us
a class and revision to look at?
As an aside, could the problem that Tim mentioned cause incorrect messages to get placed
on a queue? We have sporadic reports from our testers of incorrect messages being placed
on the queue. We only get these errors when running JBoss Messaging (i.e. not other
providers that we support) and only when running two instances. The error that they were
reporting was that callback message objects were being placed onto the queues which then
caused class cast exceptions in our application as weren't expecting that type of
message. I don't know if that makes any sense to you, but if it doesn't I can get
more information.
Thanks for the assistance,
David
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3984672#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...