You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2007/06/13 16:07:39 UTC
[java] tests failing occasionally? (was Re: Who's using specs/cluster0-9.xml)
Gordon Sim wrote:
> Alan Conway wrote:
>> On Tue, 2007-06-12 at 13:54 +0100, Gordon Sim wrote:
>>> The old cluster module will be using cluster0-8.xml I imagine; I
>>> suspect the 0-9 was just a copy of that, never actually used on trunk.
>>
>> Can you remove it if it's not required?
>
> Happy to! Last chance to for whoever created to save it... going once...
The file was added by Kim who also believes it is not used, and I've had
a scan for that file in the java project without finding any references,
so I've removed it.
Running mvn also passes... eventually! I got four failures out of ten
attempts. Anyone else still experiencing this? The errors I saw are
included below. The first one occurred three times.
testSend2ThenRollback(org.apache.qpid.test.unit.transacted.CommitRollbackTest)
Time elapsed: 0.129 sec <<< FAILURE!
junit.framework.AssertionFailedError: Messasge is marked as redelivered
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at
org.apache.qpid.test.unit.transacted.CommitRollbackTest.testSend2ThenRollback(CommitRollbackTest.java:368)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.066
sec <<< FAILURE!
testAsynchronousRecieve(org.apache.qpid.client.ResetMessageListenerTest)
Time elapsed: 0.064 sec <<< ERROR!
javax.jms.JMSException: Error closing connection:
org.apache.qpid.AMQException: AMQMethodEvent Method event:
Channel id: 1
Method: org.apache.qpid.framing.ConnectionCloseBody[ Class: 10 Method:
60] replyCode: 504 replyText: channel error [error code 504: channel
error] classId: 60 methodId: 80 was not processed by any listener.
Listeners:[org.apache.qpid.client.state.listener.SpecificMethodFrameListener@52d360]
at
org.apache.qpid.client.AMQConnection.close(AMQConnection.java:780)
at
org.apache.qpid.client.AMQConnection.close(AMQConnection.java:741)
at
org.apache.qpid.client.ResetMessageListenerTest.tearDown(ResetMessageListenerTest.java:125)
Re: [java] tests failing occasionally? (was Re: Who's using specs/cluster0-9.xml)
Posted by Martin Ritchie <ri...@apache.org>.
Shall patch the problem we spotted with the InVM Transport. Hopefully
that is causing the test problems. but it isn't immediately obvious
that it will be fixed with this patch.
On 13/06/07, Carl Trieloff <cc...@redhat.com> wrote:
>
> Can you patch this issue on trunk also?
>
> thanks
> Carl.
>
>
> Martin Ritchie wrote:
> > We did spot a problem with the InVm socket connector which may be
> > causing some problems. I shall raise the JIRA and make the small
> > change.. It should really go in with M2.
> >
> >
> > On 13/06/07, Carl Trieloff <cc...@redhat.com> wrote:
> >>
> >>
> >> yes I also see this
> >> Carl.
> >>
> >> Gordon Sim wrote:
> >> > Gordon Sim wrote:
> >> >> Alan Conway wrote:
> >> >>> On Tue, 2007-06-12 at 13:54 +0100, Gordon Sim wrote:
> >> >>>> The old cluster module will be using cluster0-8.xml I imagine; I
> >> >>>> suspect the 0-9 was just a copy of that, never actually used on
> >> trunk.
> >> >>>
> >> >>> Can you remove it if it's not required?
> >> >>
> >> >> Happy to! Last chance to for whoever created to save it... going
> >> once...
> >> >
> >> > The file was added by Kim who also believes it is not used, and I've
> >> > had a scan for that file in the java project without finding any
> >> > references, so I've removed it.
> >> >
> >> > Running mvn also passes... eventually! I got four failures out of ten
> >> > attempts. Anyone else still experiencing this? The errors I saw are
> >> > included below. The first one occurred three times.
> >> >
> >> >
> >> testSend2ThenRollback(org.apache.qpid.test.unit.transacted.CommitRollbackTest)
> >>
> >> > Time elapsed: 0.129 sec <<< FAILURE!
> >> > junit.framework.AssertionFailedError: Messasge is marked as
> >> redelivered
> >> > at junit.framework.Assert.fail(Assert.java:47)
> >> > at junit.framework.Assert.assertTrue(Assert.java:20)
> >> > at
> >> >
> >> org.apache.qpid.test.unit.transacted.CommitRollbackTest.testSend2ThenRollback(CommitRollbackTest.java:368)
> >>
> >> >
> >> >
> >> > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.066
> >> > sec <<< FAILURE!
> >> >
> >> testAsynchronousRecieve(org.apache.qpid.client.ResetMessageListenerTest)
> >> > Time elapsed: 0.064 sec <<< ERROR!
> >> > javax.jms.JMSException: Error closing connection:
> >> > org.apache.qpid.AMQException: AMQMethodEvent Method event:
> >> > Channel id: 1
> >> > Method: org.apache.qpid.framing.ConnectionCloseBody[ Class: 10 Method:
> >> > 60] replyCode: 504 replyText: channel error [error code 504: channel
> >> > error] classId: 60 methodId: 80 was not processed by any listener.
> >> >
> >> Listeners:[org.apache.qpid.client.state.listener.SpecificMethodFrameListener@52d360]
> >>
> >> >
> >> > at
> >> > org.apache.qpid.client.AMQConnection.close(AMQConnection.java:780)
> >> > at
> >> > org.apache.qpid.client.AMQConnection.close(AMQConnection.java:741)
> >> > at
> >> >
> >> org.apache.qpid.client.ResetMessageListenerTest.tearDown(ResetMessageListenerTest.java:125)
> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>
--
Martin Ritchie
Re: [java] tests failing occasionally? (was Re: Who's using specs/cluster0-9.xml)
Posted by Carl Trieloff <cc...@redhat.com>.
Can you patch this issue on trunk also?
thanks
Carl.
Martin Ritchie wrote:
> We did spot a problem with the InVm socket connector which may be
> causing some problems. I shall raise the JIRA and make the small
> change.. It should really go in with M2.
>
>
> On 13/06/07, Carl Trieloff <cc...@redhat.com> wrote:
>>
>>
>> yes I also see this
>> Carl.
>>
>> Gordon Sim wrote:
>> > Gordon Sim wrote:
>> >> Alan Conway wrote:
>> >>> On Tue, 2007-06-12 at 13:54 +0100, Gordon Sim wrote:
>> >>>> The old cluster module will be using cluster0-8.xml I imagine; I
>> >>>> suspect the 0-9 was just a copy of that, never actually used on
>> trunk.
>> >>>
>> >>> Can you remove it if it's not required?
>> >>
>> >> Happy to! Last chance to for whoever created to save it... going
>> once...
>> >
>> > The file was added by Kim who also believes it is not used, and I've
>> > had a scan for that file in the java project without finding any
>> > references, so I've removed it.
>> >
>> > Running mvn also passes... eventually! I got four failures out of ten
>> > attempts. Anyone else still experiencing this? The errors I saw are
>> > included below. The first one occurred three times.
>> >
>> >
>> testSend2ThenRollback(org.apache.qpid.test.unit.transacted.CommitRollbackTest)
>>
>> > Time elapsed: 0.129 sec <<< FAILURE!
>> > junit.framework.AssertionFailedError: Messasge is marked as
>> redelivered
>> > at junit.framework.Assert.fail(Assert.java:47)
>> > at junit.framework.Assert.assertTrue(Assert.java:20)
>> > at
>> >
>> org.apache.qpid.test.unit.transacted.CommitRollbackTest.testSend2ThenRollback(CommitRollbackTest.java:368)
>>
>> >
>> >
>> > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.066
>> > sec <<< FAILURE!
>> >
>> testAsynchronousRecieve(org.apache.qpid.client.ResetMessageListenerTest)
>> > Time elapsed: 0.064 sec <<< ERROR!
>> > javax.jms.JMSException: Error closing connection:
>> > org.apache.qpid.AMQException: AMQMethodEvent Method event:
>> > Channel id: 1
>> > Method: org.apache.qpid.framing.ConnectionCloseBody[ Class: 10 Method:
>> > 60] replyCode: 504 replyText: channel error [error code 504: channel
>> > error] classId: 60 methodId: 80 was not processed by any listener.
>> >
>> Listeners:[org.apache.qpid.client.state.listener.SpecificMethodFrameListener@52d360]
>>
>> >
>> > at
>> > org.apache.qpid.client.AMQConnection.close(AMQConnection.java:780)
>> > at
>> > org.apache.qpid.client.AMQConnection.close(AMQConnection.java:741)
>> > at
>> >
>> org.apache.qpid.client.ResetMessageListenerTest.tearDown(ResetMessageListenerTest.java:125)
>>
>> >
>> >
>>
>>
>
>
Re: [java] tests failing occasionally? (was Re: Who's using specs/cluster0-9.xml)
Posted by Martin Ritchie <ri...@apache.org>.
We did spot a problem with the InVm socket connector which may be
causing some problems. I shall raise the JIRA and make the small
change.. It should really go in with M2.
On 13/06/07, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> yes I also see this
> Carl.
>
> Gordon Sim wrote:
> > Gordon Sim wrote:
> >> Alan Conway wrote:
> >>> On Tue, 2007-06-12 at 13:54 +0100, Gordon Sim wrote:
> >>>> The old cluster module will be using cluster0-8.xml I imagine; I
> >>>> suspect the 0-9 was just a copy of that, never actually used on trunk.
> >>>
> >>> Can you remove it if it's not required?
> >>
> >> Happy to! Last chance to for whoever created to save it... going once...
> >
> > The file was added by Kim who also believes it is not used, and I've
> > had a scan for that file in the java project without finding any
> > references, so I've removed it.
> >
> > Running mvn also passes... eventually! I got four failures out of ten
> > attempts. Anyone else still experiencing this? The errors I saw are
> > included below. The first one occurred three times.
> >
> > testSend2ThenRollback(org.apache.qpid.test.unit.transacted.CommitRollbackTest)
> > Time elapsed: 0.129 sec <<< FAILURE!
> > junit.framework.AssertionFailedError: Messasge is marked as redelivered
> > at junit.framework.Assert.fail(Assert.java:47)
> > at junit.framework.Assert.assertTrue(Assert.java:20)
> > at
> > org.apache.qpid.test.unit.transacted.CommitRollbackTest.testSend2ThenRollback(CommitRollbackTest.java:368)
> >
> >
> > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.066
> > sec <<< FAILURE!
> > testAsynchronousRecieve(org.apache.qpid.client.ResetMessageListenerTest)
> > Time elapsed: 0.064 sec <<< ERROR!
> > javax.jms.JMSException: Error closing connection:
> > org.apache.qpid.AMQException: AMQMethodEvent Method event:
> > Channel id: 1
> > Method: org.apache.qpid.framing.ConnectionCloseBody[ Class: 10 Method:
> > 60] replyCode: 504 replyText: channel error [error code 504: channel
> > error] classId: 60 methodId: 80 was not processed by any listener.
> > Listeners:[org.apache.qpid.client.state.listener.SpecificMethodFrameListener@52d360]
> >
> > at
> > org.apache.qpid.client.AMQConnection.close(AMQConnection.java:780)
> > at
> > org.apache.qpid.client.AMQConnection.close(AMQConnection.java:741)
> > at
> > org.apache.qpid.client.ResetMessageListenerTest.tearDown(ResetMessageListenerTest.java:125)
> >
> >
>
>
--
Martin Ritchie
Re: [java] tests failing occasionally? (was Re: Who's using specs/cluster0-9.xml)
Posted by Carl Trieloff <cc...@redhat.com>.
yes I also see this
Carl.
Gordon Sim wrote:
> Gordon Sim wrote:
>> Alan Conway wrote:
>>> On Tue, 2007-06-12 at 13:54 +0100, Gordon Sim wrote:
>>>> The old cluster module will be using cluster0-8.xml I imagine; I
>>>> suspect the 0-9 was just a copy of that, never actually used on trunk.
>>>
>>> Can you remove it if it's not required?
>>
>> Happy to! Last chance to for whoever created to save it... going once...
>
> The file was added by Kim who also believes it is not used, and I've
> had a scan for that file in the java project without finding any
> references, so I've removed it.
>
> Running mvn also passes... eventually! I got four failures out of ten
> attempts. Anyone else still experiencing this? The errors I saw are
> included below. The first one occurred three times.
>
> testSend2ThenRollback(org.apache.qpid.test.unit.transacted.CommitRollbackTest)
> Time elapsed: 0.129 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Messasge is marked as redelivered
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.apache.qpid.test.unit.transacted.CommitRollbackTest.testSend2ThenRollback(CommitRollbackTest.java:368)
>
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.066
> sec <<< FAILURE!
> testAsynchronousRecieve(org.apache.qpid.client.ResetMessageListenerTest)
> Time elapsed: 0.064 sec <<< ERROR!
> javax.jms.JMSException: Error closing connection:
> org.apache.qpid.AMQException: AMQMethodEvent Method event:
> Channel id: 1
> Method: org.apache.qpid.framing.ConnectionCloseBody[ Class: 10 Method:
> 60] replyCode: 504 replyText: channel error [error code 504: channel
> error] classId: 60 methodId: 80 was not processed by any listener.
> Listeners:[org.apache.qpid.client.state.listener.SpecificMethodFrameListener@52d360]
>
> at
> org.apache.qpid.client.AMQConnection.close(AMQConnection.java:780)
> at
> org.apache.qpid.client.AMQConnection.close(AMQConnection.java:741)
> at
> org.apache.qpid.client.ResetMessageListenerTest.tearDown(ResetMessageListenerTest.java:125)
>
>
Re: [java] tests failing occasionally?
Posted by Daniel Kulp <da...@iona.com>.
On Friday 15 June 2007 06:38, Rupert Smith wrote:
> Anyone know what the maven 2 property to allow the build to complete
> succesfully despite test failures is? That would be a really handy one
> to know.
Couple options...
When you run mvn, you can add:
-fn - fail never
-fae - fails at the end (after all the builds are done)
-Dmaven.test.failure.ignore=true
Dan
>
> Rupert
>
> On 15/06/07, Gordon Sim <gs...@redhat.com> wrote:
> > Martin Ritchie wrote:
> > > Gordon, were these failures on M2 or trunk?
> >
> > Trunk only. I ran the build on M2 several (+5) times with no
> > failures.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: [java] tests failing occasionally?
Posted by Robert Godfrey <ro...@gmail.com>.
Of course JMS has no notion of "pre-fetch"... So the answer, if you
want to have true JMS compliance is to turn pre-fetch off (if one can)
:-)
-- Rob
On 15/06/07, Martin Ritchie <ri...@apache.org> wrote:
> On 15/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> > Before you start puzzling why on trunk and not on M2, I think
> > CommitRollbackTest.testSend2ThenRollback was commented out on M2. A crime to
> > which I confess...
> >
> > Anyone know what the maven 2 property to allow the build to complete
> > succesfully despite test failures is? That would be a really handy one to
> > know.
> >
> > Rupert
> >
> > On 15/06/07, Gordon Sim <gs...@redhat.com> wrote:
> > >
> > > Martin Ritchie wrote:
> > > > Gordon, were these failures on M2 or trunk?
> > >
> > > Trunk only. I ran the build on M2 several (+5) times with no failures.
> > >
>
> I've tidied up the test on M2 so will send it to trunk.The test was
> fairly race condition related but raised an interesting JMS question.
>
> I don't remember the spec in detail but when should a message be
> classed as redelivered?
>
> If a message is prefetched then purged from the prefetch due to
> rollback is it redelivered? The 'client' hasn't see the message so
> should it be redelivered? Correct ordering is certainly an issue and
> marking it redelivered is probably a safe option. But I think in this
> test case:
>
> send 1,2 : receive 1 : rollback : receive
>
> the messages that should arrive are 1 (re-delivered) and 2. The order
> is not defined but message 2 hasn't been seen by the real client code.
> The Qpid Client framework has seen it but I don't think that counts.
>
> Currently the code allows for message 2 to arrive twice as long as the
> redelivered flag is true on one and false on the other.
>
> --
> Martin Ritchie
>
Re: [java] tests failing occasionally?
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> I don't remember the spec in detail but when should a message be
> classed as redelivered?
The JMS spec states that "A session must set the redelivered flag of
messages it redelivers due to a recovery" (4.4.11). Rollback is defined
as automatically recovering consumed messages (4.4.7).
There is still ambiguity: it isn't explicitly stated whether that
applies to messages that were sent to the session but which the
application has not seen i.e. that have not been acknowledged (i.e.
whether it applies to 'prefetched' messages).
As you say, the safe option is to set redelivered. As Rob points out JMS
doesn't directly deal with prefetching which explains this ambiguity (to
a degree at least) You can always turn off prefetching. I'd argue that
AUTO_ACKNOWLEDGE implies no prefetching, whereas DUPS_OK_ACKNOWLEDGE
allows it, but thats another issue really.
Re: [java] tests failing occasionally?
Posted by Martin Ritchie <ri...@apache.org>.
On 15/06/07, Rupert Smith <ru...@googlemail.com> wrote:
> Before you start puzzling why on trunk and not on M2, I think
> CommitRollbackTest.testSend2ThenRollback was commented out on M2. A crime to
> which I confess...
>
> Anyone know what the maven 2 property to allow the build to complete
> succesfully despite test failures is? That would be a really handy one to
> know.
>
> Rupert
>
> On 15/06/07, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Martin Ritchie wrote:
> > > Gordon, were these failures on M2 or trunk?
> >
> > Trunk only. I ran the build on M2 several (+5) times with no failures.
> >
I've tidied up the test on M2 so will send it to trunk.The test was
fairly race condition related but raised an interesting JMS question.
I don't remember the spec in detail but when should a message be
classed as redelivered?
If a message is prefetched then purged from the prefetch due to
rollback is it redelivered? The 'client' hasn't see the message so
should it be redelivered? Correct ordering is certainly an issue and
marking it redelivered is probably a safe option. But I think in this
test case:
send 1,2 : receive 1 : rollback : receive
the messages that should arrive are 1 (re-delivered) and 2. The order
is not defined but message 2 hasn't been seen by the real client code.
The Qpid Client framework has seen it but I don't think that counts.
Currently the code allows for message 2 to arrive twice as long as the
redelivered flag is true on one and false on the other.
--
Martin Ritchie
Re: [java] tests failing occasionally?
Posted by Rupert Smith <ru...@googlemail.com>.
Before you start puzzling why on trunk and not on M2, I think
CommitRollbackTest.testSend2ThenRollback was commented out on M2. A crime to
which I confess...
Anyone know what the maven 2 property to allow the build to complete
succesfully despite test failures is? That would be a really handy one to
know.
Rupert
On 15/06/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Martin Ritchie wrote:
> > Gordon, were these failures on M2 or trunk?
>
> Trunk only. I ran the build on M2 several (+5) times with no failures.
>
>
Re: [java] tests failing occasionally?
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> Gordon, were these failures on M2 or trunk?
Trunk only. I ran the build on M2 several (+5) times with no failures.
Re: [java] tests failing occasionally? (was Re: Who's using specs/cluster0-9.xml)
Posted by Martin Ritchie <ri...@apache.org>.
On 13/06/07, Gordon Sim <gs...@redhat.com> wrote:
> Gordon Sim wrote:
> > Alan Conway wrote:
> >> On Tue, 2007-06-12 at 13:54 +0100, Gordon Sim wrote:
> >>> The old cluster module will be using cluster0-8.xml I imagine; I
> >>> suspect the 0-9 was just a copy of that, never actually used on trunk.
> >>
> >> Can you remove it if it's not required?
> >
> > Happy to! Last chance to for whoever created to save it... going once...
>
> The file was added by Kim who also believes it is not used, and I've had
> a scan for that file in the java project without finding any references,
> so I've removed it.
>
> Running mvn also passes... eventually! I got four failures out of ten
> attempts. Anyone else still experiencing this? The errors I saw are
> included below. The first one occurred three times.
>
> testSend2ThenRollback(org.apache.qpid.test.unit.transacted.CommitRollbackTest)
> Time elapsed: 0.129 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Messasge is marked as redelivered
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at
> org.apache.qpid.test.unit.transacted.CommitRollbackTest.testSend2ThenRollback(CommitRollbackTest.java:368)
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.066
> sec <<< FAILURE!
> testAsynchronousRecieve(org.apache.qpid.client.ResetMessageListenerTest)
> Time elapsed: 0.064 sec <<< ERROR!
> javax.jms.JMSException: Error closing connection:
> org.apache.qpid.AMQException: AMQMethodEvent Method event:
> Channel id: 1
> Method: org.apache.qpid.framing.ConnectionCloseBody[ Class: 10 Method:
> 60] replyCode: 504 replyText: channel error [error code 504: channel
> error] classId: 60 methodId: 80 was not processed by any listener.
> Listeners:[org.apache.qpid.client.state.listener.SpecificMethodFrameListener@52d360]
> at
> org.apache.qpid.client.AMQConnection.close(AMQConnection.java:780)
> at
> org.apache.qpid.client.AMQConnection.close(AMQConnection.java:741)
> at
> org.apache.qpid.client.ResetMessageListenerTest.tearDown(ResetMessageListenerTest.java:125)
Gordon, were these failures on M2 or trunk?
--
Martin Ritchie