qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: [jira] Created: (QPID-346) Message loss after rollback
Date Thu, 08 Feb 2007 16:30:36 GMT
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 <kim.vdriet@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 <cctrieloff@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

Mime
View raw message