You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2008/12/04 10:55:45 UTC

[jira] Updated: (QPID-580) MessageRequeueTest.testTwoCompetingConsumers occasionally fails

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

Marnie McCormack updated QPID-580:
----------------------------------

    Fix Version/s:     (was: M4)

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