"clebert.suconic(a)jboss.com" wrote :
| The exception was breaking failover... and messages were getting lost. (Until a restart on server)
Probably because you weren't closing the session.
If the recovery failed halfway then the session will still contain deliveries corresponding to the "missing" messages.
The client then gets an exception and closes the session, the deliveries will then get cancelled back to the queue.
If the client crashes the server side cleanup will automatically close the session. In any cas there is no need to make the recovery atomic.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059403#4059403
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059403
anonymous wrote : Imagine if the cancel or recovery of several message failed half way. The session would eventually get closed and the remaining messages would end up back on the queue. No messages would be lost and we wouldn't have broken any of our transactional promises.
This is not the behavior I saw on testcases..
The exception was breaking failover... and messages were getting lost. (Until a restart on server)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059398#4059398
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059398
I'll re-iterate what I said before.
The only things that execute in a transactional context are sending and ack of messages. These are the only things for which we give a transactional guarantee.
Cancelling and recovering don't need to be atomic.
Why?
Imagine if the cancel or recovery of several message failed half way. The session would eventually get closed and the remaining messages would end up back on the queue. No messages would be lost and we wouldn't have broken any of our transactional promises.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059395#4059395
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059395
"clebert.suconic(a)jboss.com" wrote : Just an update...
|
| Another point I'm dealing with on this task, is to make ServerSessionEndpoing::recoverDeliveries atomic.
|
| Case anything goes wrong with the execution of Queue::recoverDeliveries... ServerSessionEndpoing::recoverDeliveries needs to keep messages untouched.
|
It doesn't need to be atomic.
The only things that need to be atomic are transactional sends and acks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059387#4059387
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059387
anonymous wrote : recovery is done on a per session level, not connection or consumer. so the session should be invalidated
Right...
Think about the two sessions case then?
One Connection , two sessions, each one with a consumer on a different queue.
If session1 can't find ACKs and session2 find ACKs, we want only session1 invalidated, right?
Right now Exceptions are handled on FailoverCommandCenter... I will be adding exception handling for each Session now on SessionState.synchronizeWith.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059294#4059294
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059294