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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
