qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marnie McCormack (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-142) Transactions not atomic in the face of fail over
Date Fri, 19 Jan 2007 15:12:30 GMT

    [ 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


View raw message