You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2007/02/06 15:21:05 UTC
[jira] Created: (QPID-346) Message loss after rollback
Message loss after rollback
---------------------------
Key: QPID-346
URL: https://issues.apache.org/jira/browse/QPID-346
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: M1
Reporter: Marnie McCormack
Rolling back a transaction after a message consume alwasy results in the loss of a message
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (QPID-346) Message loss after rollback
Posted by Martin Ritchie <ri...@apache.org>.
On 8 Feb 2007, at 17:22, Gordon Sim wrote:
> Martin Ritchie wrote:
>> TxRollback seems to have problems both in our Qpid Java
>> implementation
>> and the AMQP method.
>
> What is the problem with the AMQP method?
When I wrote the JIRA I felt that the TxRollback should leave the
channel suspended so the client can ensure that they clean their
prefetch catch before re-flowing the messages. However as I created a
JIRA over on AMQP for clarification about this I wondered if doing
the clean up on the TxRollbackOk handler would be sufficient. I was
going from the code that was already their in the client. I had a
mental block on the fact that there could be a handler for the Ok. I
don't believe we have one currently. I'll look at that in the morning.
This was related to the Basic.Recover method that was added in the
Qpid Java client for recovery. It is async and so needs flow control
"locking" around it .. If it were synchronous then it took could have
a Ok handler to clean up.
Does that seem right to you? I know your not that familiar with the
Java code. Sometimes it helps to take a step back and look at how
something is being fixed and not just that it gets fixed.
:)
--
Martin
Re: [jira] Created: (QPID-346) Message loss after rollback
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> TxRollback seems to have problems both in our Qpid Java implementation
> and the AMQP method.
What is the problem with the AMQP method?
Re: [jira] Created: (QPID-346) Message loss after rollback
Posted by Martin Ritchie <ri...@apache.org>.
TxRollback seems to have problems both in our Qpid Java implementation
and the AMQP method. We noticed the issue whilst testing on the
perftesting branch that rollback doesn't quite work. I have commited a
fix to that branch and shall merge the changes to trunk soon.
While your changes to the test will have fixed an issue with the test
it doesn't address the code problems.
If you delete this line 137 in rollBackTest
expect("C", consumer1.receive(1000));
So not all of the published messages are consumed on the client and
then perform a roll back you will see the start of the problems.
The prefetch cache needs to be cleared but there are also issues
around requeuing the messages on the broker. The JMS spec says a
rollback should behave similar to a recover which means if the queue
receives a higher priority message whilst you are recovering that
higher priority message should be sent first.
On 08/02/07, Kim van der Riet <ki...@redhat.com> wrote:
> On Thu, 2007-02-08 at 09:20 +0000, Marnie McCormack wrote:
> > Hi Carl & Kim,
> >
> > Are there any applicable JIRAs I can look at for pointers ?
> >
> > Thanks,
> > Marnie
> >
> >
> > On 2/6/07, Carl Trieloff <cc...@redhat.com> wrote:
> > >
> > >
> > > Quite a few issues where found in this area on the 0-9 branch. I might
> > > be good to sync up with Kim on the
> > > issues resolved on the 0-9 branch that have not been merged back to
> > > trunk yet.
> > >
> > > Carl.
> > >
> > >
> > > Marnie McCormack (JIRA) wrote:
> > > > Message loss after rollback
> > > > ---------------------------
> > > >
> > > > Key: QPID-346
> > > > URL: https://issues.apache.org/jira/browse/QPID-346
> > > > Project: Qpid
> > > > Issue Type: Bug
> > > > Components: Java Client
> > > > Affects Versions: M1
> > > > Reporter: Marnie McCormack
> > > >
> > > >
> > > > Rolling back a transaction after a message consume alwasy results in the
> > > loss of a message
> > > >
> > > >
> I am not certain whether this is directly related to your problem, but
> here are the details:
>
> I have found that there is a problem with rollback() on the trunk
> (mirrored in the 0-9 branch, but solved there), and the following patch
> to TransactedTest reveals the problem. Part of the changes in the patch
> move the creation of messages A,B,C into the two (original) tests that
> use them, as the later addition of the
> testResendsMsgsAfterSessionClose() method does not use these, and leaves
> them around for later tests to stumble across.
>
> If you patch the test, and run
>
> mvn -Dtest=TransactedTest test
>
> then you will see the following:
>
> Running org.apache.qpid.test.unit.transacted.TransactedTest
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.639 sec <<< FAILURE!
> testEmpty2(org.apache.qpid.test.unit.transacted.TransactedTest) Time elapsed: 1.064 sec <<< FAILURE!
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertTrue(Assert.java:27)
> at org.apache.qpid.test.unit.transacted.TransactedTest.testEmpty2(TransactedTest.java:181)
>
> which indicates that the messages X,Y,Z are still around after the
> rollback test completed. If the commit() method on line 158 (post-patch)
> is uncommented, then the failure changes to:
>
> Running org.apache.qpid.test.unit.transacted.TransactedTest
> Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.689 sec <<< FAILURE!
> testRollback(org.apache.qpid.test.unit.transacted.TransactedTest) Time elapsed: 1.09 sec <<< FAILURE!
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertTrue(Assert.java:27)
> at org.apache.qpid.test.unit.transacted.TransactedTest.testRollback(TransactedTest.java:167)
>
> which shows that inspite the rollback, X,Y,Z were still downloaded.
>
> Take a look at r501577 for how this was solved on the 0-9 branch.
>
> Note that the changes to the definition of queue Q1 on line 61 made
> earlier on the trunk may mask certain problems related to this... If
> this line is changed back to
>
> queue1 = new AMQQueue("Q1", false);
>
> then if there are still messages left over from the test, they tend to
> interfere with one of the later tests (RecoverTest, I think) when the
> entire test suite is run together. For this reason I added the empty
> checks after each test which consume any left-over messages in the
> process of reporting the error. Ideally, tests should clean up after
> themselves, and not leave stray messages around. Making the queue
> temporary, as this change did, may have masked the underlying problem.
>
> I plan to check this change to TransactedTest into Subversion at some
> point, if you find that it is appropriate, you can do so for me...
>
> I hope this helps,
> Kim
>
>
--
Martin Ritchie
Re: [jira] Created: (QPID-346) Message loss after rollback
Posted by Kim van der Riet <ki...@redhat.com>.
On Thu, 2007-02-08 at 09:20 +0000, Marnie McCormack wrote:
> Hi Carl & Kim,
>
> Are there any applicable JIRAs I can look at for pointers ?
>
> Thanks,
> Marnie
>
>
> On 2/6/07, Carl Trieloff <cc...@redhat.com> wrote:
> >
> >
> > Quite a few issues where found in this area on the 0-9 branch. I might
> > be good to sync up with Kim on the
> > issues resolved on the 0-9 branch that have not been merged back to
> > trunk yet.
> >
> > Carl.
> >
> >
> > Marnie McCormack (JIRA) wrote:
> > > Message loss after rollback
> > > ---------------------------
> > >
> > > Key: QPID-346
> > > URL: https://issues.apache.org/jira/browse/QPID-346
> > > Project: Qpid
> > > Issue Type: Bug
> > > Components: Java Client
> > > Affects Versions: M1
> > > Reporter: Marnie McCormack
> > >
> > >
> > > Rolling back a transaction after a message consume alwasy results in the
> > loss of a message
> > >
> > >
I am not certain whether this is directly related to your problem, but
here are the details:
I have found that there is a problem with rollback() on the trunk
(mirrored in the 0-9 branch, but solved there), and the following patch
to TransactedTest reveals the problem. Part of the changes in the patch
move the creation of messages A,B,C into the two (original) tests that
use them, as the later addition of the
testResendsMsgsAfterSessionClose() method does not use these, and leaves
them around for later tests to stumble across.
If you patch the test, and run
mvn -Dtest=TransactedTest test
then you will see the following:
Running org.apache.qpid.test.unit.transacted.TransactedTest
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.639 sec <<< FAILURE!
testEmpty2(org.apache.qpid.test.unit.transacted.TransactedTest) Time elapsed: 1.064 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at org.apache.qpid.test.unit.transacted.TransactedTest.testEmpty2(TransactedTest.java:181)
which indicates that the messages X,Y,Z are still around after the
rollback test completed. If the commit() method on line 158 (post-patch)
is uncommented, then the failure changes to:
Running org.apache.qpid.test.unit.transacted.TransactedTest
Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.689 sec <<< FAILURE!
testRollback(org.apache.qpid.test.unit.transacted.TransactedTest) Time elapsed: 1.09 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at org.apache.qpid.test.unit.transacted.TransactedTest.testRollback(TransactedTest.java:167)
which shows that inspite the rollback, X,Y,Z were still downloaded.
Take a look at r501577 for how this was solved on the 0-9 branch.
Note that the changes to the definition of queue Q1 on line 61 made
earlier on the trunk may mask certain problems related to this... If
this line is changed back to
queue1 = new AMQQueue("Q1", false);
then if there are still messages left over from the test, they tend to
interfere with one of the later tests (RecoverTest, I think) when the
entire test suite is run together. For this reason I added the empty
checks after each test which consume any left-over messages in the
process of reporting the error. Ideally, tests should clean up after
themselves, and not leave stray messages around. Making the queue
temporary, as this change did, may have masked the underlying problem.
I plan to check this change to TransactedTest into Subversion at some
point, if you find that it is appropriate, you can do so for me...
I hope this helps,
Kim
Re: [jira] Created: (QPID-346) Message loss after rollback
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Carl & Kim,
Are there any applicable JIRAs I can look at for pointers ?
Thanks,
Marnie
On 2/6/07, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> Quite a few issues where found in this area on the 0-9 branch. I might
> be good to sync up with Kim on the
> issues resolved on the 0-9 branch that have not been merged back to
> trunk yet.
>
> Carl.
>
>
> Marnie McCormack (JIRA) wrote:
> > Message loss after rollback
> > ---------------------------
> >
> > Key: QPID-346
> > URL: https://issues.apache.org/jira/browse/QPID-346
> > Project: Qpid
> > Issue Type: Bug
> > Components: Java Client
> > Affects Versions: M1
> > Reporter: Marnie McCormack
> >
> >
> > Rolling back a transaction after a message consume alwasy results in the
> loss of a message
> >
> >
>
>
Re: [jira] Created: (QPID-346) Message loss after rollback
Posted by Carl Trieloff <cc...@redhat.com>.
Quite a few issues where found in this area on the 0-9 branch. I might
be good to sync up with Kim on the
issues resolved on the 0-9 branch that have not been merged back to
trunk yet.
Carl.
Marnie McCormack (JIRA) wrote:
> Message loss after rollback
> ---------------------------
>
> Key: QPID-346
> URL: https://issues.apache.org/jira/browse/QPID-346
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M1
> Reporter: Marnie McCormack
>
>
> Rolling back a transaction after a message consume alwasy results in the loss of a message
>
>
[jira] Resolved: (QPID-346) Message loss after rollback\recover
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie resolved QPID-346.
---------------------------------
Resolution: Fixed
Resolved at r517638
> Message loss after rollback\recover
> -----------------------------------
>
> Key: QPID-346
> URL: https://issues.apache.org/jira/browse/QPID-346
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
>
> Rolling back a transaction after a message consume alwasy results in the loss of a message
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-346) Message loss after rollback
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie reassigned QPID-346:
-----------------------------------
Assignee: Martin Ritchie
> Message loss after rollback
> ---------------------------
>
> Key: QPID-346
> URL: https://issues.apache.org/jira/browse/QPID-346
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
>
> Rolling back a transaction after a message consume alwasy results in the loss of a message
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-346) Message loss after rollback\recover
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471740 ]
Martin Ritchie commented on QPID-346:
-------------------------------------
The message order is not correctly maintained as per the JMS Spec. nor is the Suspened status of the channel. Currently the messages are automatically resent to the client regardless of the suspended status of the channel and regardless of any higher priority messages that might be pending. Not that we have priority yet.
> Message loss after rollback\recover
> -----------------------------------
>
> Key: QPID-346
> URL: https://issues.apache.org/jira/browse/QPID-346
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
>
> Rolling back a transaction after a message consume alwasy results in the loss of a message
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-346) Message loss after rollback\recover
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-346:
--------------------------------
Summary: Message loss after rollback\recover (was: Message loss after rollback)
As recover uses the same code it too is affected.
> Message loss after rollback\recover
> -----------------------------------
>
> Key: QPID-346
> URL: https://issues.apache.org/jira/browse/QPID-346
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
>
> Rolling back a transaction after a message consume alwasy results in the loss of a message
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.