You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rafael H. Schloming (JIRA)" <qp...@incubator.apache.org> on 2007/09/05 22:39:33 UTC
[jira] Created: (QPID-580)
MessageRequeueTest.testTwoCompetingConsumers occasionally fails
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.
[jira] Updated: (QPID-580)
MessageRequeueTest.testTwoCompetingConsumers occasionally fails
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ 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.
[jira] Commented: (QPID-580)
MessageRequeueTest.testTwoCompetingConsumers occasionally fails
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ 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.