You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Steven Shaw (JIRA)" <qp...@incubator.apache.org> on 2006/11/30 20:10:20 UTC
[jira] Created: (QPID-142) Transactions not atomic in the face of
fail over
Transactions not atomic in the face of fail over
------------------------------------------------
Key: QPID-142
URL: http://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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (QPID-142) Transactions not atomic in the face of fail over
Posted by Steven Shaw <st...@gmail.com>.
On 30/11/06, Carl Trieloff <cc...@redhat.com> wrote:
> I think option 2 is better as this issue should be able to be delt with
> better, with the new transport proposal released with the 0-9 spec next
> month.
Gordon preferred too when I asked him some time ago. It looks best. I
was just porting a couple of JIRAs that got left behind prior to
incubation.
Re: [jira] Created: (QPID-142) Transactions not atomic in the face
of fail over
Posted by Carl Trieloff <cc...@redhat.com>.
Steven Shaw (JIRA) wrote:
> Transactions not atomic in the face of fail over
> ------------------------------------------------
>
> Key: QPID-142
> URL: http://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.
>
>
I think option 2 is better as this issue should be able to be delt with
better, with the new transport proposal released with the 0-9 spec next
month.
Carl.
[jira] Commented: (QPID-142) Transactions not atomic in the face of
fail over
Posted by "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
[jira] Updated: (QPID-142) Transactions not atomic in the face of
fail over
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner updated QPID-142:
-------------------------------
Fix Version/s: M3
Assignee: Aidan Skinner (was: Robert Greig)
Affects Version/s: M3
> 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
> Affects Versions: M3
> Reporter: Steven Shaw
> Assignee: Aidan Skinner
> Fix For: M3
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-142) Transactions not atomic in the face of
fail over
Posted by "John O'Hara (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468843 ]
John O'Hara commented on QPID-142:
----------------------------------
Agree 2 is the *only* way to go.
It's what every other technology I've seen does -- there is no way to reliable continue a current transaction after a failure (even Oracle RAC can't do it, except for some cheating with r/o queries).
However, I don't think sending a Failover Exception is at all viable. If you're failing, you don't (normally) expect it. So there will be no warning.
It is possible that for admin reasons you could issue a administrative failover; but I would warn against that. It provides more optionality on the code paths, which provides more opportunity for errors on both the client and the server.
We must be draconian about always knowing the state of the client and server. Any indeterminate state must assume a failure.
- it either works, or it doesn't work. No in-betweens.
John
> 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
> Assigned To: Robert Greig
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-142) Transactions not atomic in the face of
fail over
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack reassigned QPID-142:
-------------------------------------
Assignee: Robert Greig
> 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
> Assigned To: Robert Greig
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-142) Transactions not atomic in the face of
fail over
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-142:
----------------------------------
Fix Version/s: (was: M4)
Descoping items not being worked on for M4 into Unknown Fix Version for now
> 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
> Affects Versions: M3
> Reporter: Steven Shaw
> Assignee: Aidan Skinner
>
> 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.
-
You can reply to this email to add a comment to the issue online.