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