qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-580) MessageRequeueTest.testTwoCompetingConsumers occasionally fails
Date Fri, 07 Sep 2007 14:53:31 GMT

    [ https://issues.apache.org/jira/browse/QPID-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525735
] 

Martin Ritchie commented on QPID-580:
-------------------------------------

The test was originally written with two but was increased to four but never renamed to something
more accurate testCompetingConsumers. The fourth consumer should of course be included but
its lack of inclusion should affect the test. This is run using inVM broker but even over
TCP it should never take more than 3seconds to receive a message. I would find it unlikely
on that any of the threads were CPU starved with only 150 msgs. being sent. If they are being
starved for anyother reason then the test should fail. As this was one of the issues this
test was for.

Agreed an additional check of messages still in the broker would be prudent.

> MessageRequeueTest.testTwoCompetingConsumers occasionally fails
> ---------------------------------------------------------------
>
>                 Key: QPID-580
>                 URL: https://issues.apache.org/jira/browse/QPID-580
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker, Java Client
>            Reporter: Rafael H. Schloming
>
> There are a few odd things about this test as it is written. It is called test*Two*CompetingConsumers,
however it actually creates 4 consumers and then only starts 3 out of the 4. Also, the way
the test is constructed, it is theoretically possible for it to fail even though there is
no bug. This is because each competing consumer will exit whenever it takes longer than 3
seconds to retrieve a message. This makes it impossible to tell whether the test is failing
because messages have been lost, or whether it is simply failing because messages remain in
the queue. The former would indicate a real bug, whereas the latter could occasionally occur
spontaneously if the competing threads get starved.
> We should probably check the number of messages left in the queue and fail with a different
assertion of messages have actually been lost. This should tell us if the occasional failures
are spurious or not and if so permit us to tune the retrieve timeout in order to avoid them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message