[jira] Commented: (QPID-142) Transactions not atomic in the face of fail over

["Marnie McCormack (JIRA)" <qp...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466076 ] 

Marnie McCormack commented on QPID-142:
---------------------------------------

RGreig/MR/MM discussed Thurs 18th Jan - notes below:

- think option 2 is appropriate
- expect that best solution is for client to get FailoverException when it happens so they do not carry on sending until commit (think big batches and can see why this is)
- need clients to implement a ConnectionListener to catch the FailoverException (org.apache.qpid.jms.ConnectionListener)
- clients should then rewind their transaction i.e. remember what they had tried to send and reset to send it again after failover (reset a loop counter prob)
- allow failover to proceed
- then start sending again from the appropriate point 

Need to look at:

- org.apache.qpid.client.state.StateWaiter.waituntilStateHasChanged() which wraps FailoverException (comment in FIXME) and looks like it prevents the FailoverException being thrown back to the client code

> Transactions not atomic in the face of fail over
> ------------------------------------------------
>
>                 Key: QPID-142
>                 URL: https://issues.apache.org/jira/browse/QPID-142
>             Project: Qpid
>          Issue Type: Bug
>          Components: Dot Net Client, Java Client
>            Reporter: Steven Shaw
>
> When some messages are already published in a transaction when fail over occurs, those messages will be lost.
> Options seem to be:
>   1. Remembering and replaying sent messages (in a Tx)
>   2. Aborting any in-flight transactions on failover
> 1 could be costly in terms of memory for applications using transaction. 2 could be annoying for applications requiring the use of retry loops (however these retry loops are often necessary in any case and can sometimes be injected via AOP).
> I asked Gordon's opinion and he favored (2) as well.
> In addition to this we need to ensure that the broker issues a Channel.Close when it gets a Tx.Commit without a prior Tx.Select. It's not clear what error code should be used. Invalid-command (503) looks close but is a hard-error. Check the amqp-dev list for discussion on this topic.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira