Re: [java] tests failing occasionally?

[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?

[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?

[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?

[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?

[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?

[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.
>
>