There is one problem with that though...
Suppose a connection has one session, two consumers, consumerA, consumerB... one on each queue...
ConsumerA will failOver OK, while ConsumerB won't recover acks.
Should we invalidate the whole connection... closing also ConsumerA... or should we invalidate only ConsumerB?
I believe we should invalidate the whole connection... as the failover is supposed to perform as a whole IMO, but I wanted to discuss that first.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059292#4059292
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059292
Discussion of http://jira.jboss.com/jira/browse/JBMESSAGING-1006
As part of 1006, ChannelSupport:recoverDeliveries will throw an exception if it can't find a delivery to recover on messageRefs.
This will certainly cause Failover to fail... so the connection that couldn't get a proper failover should be invalidated in such state that no invocation should be made.
But it happens that a messageConsumer.receive() is going through ok, even if the failover was aborted.
I have tried few combinations such as closing the connectionDelegate on FailoverCommandCenter, but it didn't work as a close would try to communicate on server.
So I want to create a method on DelegateSupport, called invalidate, which will be intercepted by ClosedInterceptor and will throw an exception to any call to any Delegate that failed after a failover. This way a call to messageConsumer.receive() would throw a proper exception to the client.
Let me know if you see any issues.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059263#4059263
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059263
Discussion of http://jira.jboss.com/jira/browse/JBMESSAGING-1006
As part of 1006, ChannelSupport:recoverDeliveries will throw an exception if it can't find a delivery to recover on messageRefs.
This will certainly cause Failover to fail... so the connection that couldn't get a proper failover should be invalidated in such state that no connection should be made.
But it happens that a messageConsumer.receive() is going through ok, even if the failover was aborted.
I have tried few combinations such as closing the connectionDelegate on FailoverCommandCenter, but it didn't work as a close would try to communicate on server.
So I want to create a method on DelegateSupport, called invalidate, which will be intercepted by ClosedInterceptor and will throw an exception to any call to any Delegate that failed after a failover. This way a call to messageConsumer.receive() would throw a proper exception to the client.
Let me know if you see any issues.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059263#4059263
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059263
I have got it working locally but I will need to add some more tests to make sure it's implemented correctly. I had to collect all those lastDeliveryIDs into a map on the server side and send them back to the client in a ConnectionStopResponse packet that I created.
Do we really have to wait for the delivery lastDeliveryID to come in this case? Wouldn't it be possible for ClientConsumer to still accept messages as usual when stopped but not deliver them to receive() and onMessage()? Then Connection.stop() could tell the server side to stop, wait until every ClientConsumer finishes any onMessage calls it has already started and return afterwards?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059236#4059236
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059236
One other point. You shouldn't be using the main deployer to create webcontexts.
You should just be adding WebMetaData to your deployment.
That was one of the main reasons for the Deployers changes.
A single deployment can be both a web deployment and an ejb deployment,
exactly because this occurs in webservices.
The hack to create a new deployment for the web-app is a hangover from the JBoss4
limitiations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059205#4059205
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059205