[
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
