You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rupert Smith (JIRA)" <qp...@incubator.apache.org> on 2007/09/26 12:28:50 UTC
[jira] Created: (QPID-616) Message Loss in NO_ACK Mode.
Message Loss in NO_ACK Mode.
----------------------------
Key: QPID-616
URL: https://issues.apache.org/jira/browse/QPID-616
Project: Qpid
Issue Type: Bug
Components: Java Broker, Java Client
Affects Versions: M2
Environment: Java client and broker, M2.
Reporter: Rupert Smith
Assignee: Rupert Smith
Fix For: M2
The test:
./Ping-Once-Async.sh -c[8] -s[1000] -d1D ackMode=257 pubsub=true destinationCount=10 messageSize=5000 persistent=false transacted=false broker=tcp://10.0.0.1:9000 consAckMode=257 consTransacted=false maxPending=500000 uniqueDests=false -o no_ack_test/ -n NoAckPubSub
Jams after a while. On every message sent it increments a count, on every message received it decrements. A maximum count limit is set to prevent the test from OOMEing the broker. If messages are lost, and never received, the count will eventually hit its maximum value and jam the test.
Investigate possible message loss in NO_ACK mode.
Add a time-out into the test to fail it when this happens.
Add numbering of messages to the test. Messages should arrive in the order they are sent, so message loss should show up as a gap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-616) Message Loss in NO_ACK Mode.
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530430 ]
Rupert Smith commented on QPID-616:
-----------------------------------
This is due to an underflow in the pending messages calculation in the test.
Will fix the test.
> Message Loss in NO_ACK Mode.
> ----------------------------
>
> Key: QPID-616
> URL: https://issues.apache.org/jira/browse/QPID-616
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client
> Affects Versions: M2
> Environment: Java client and broker, M2.
> Reporter: Rupert Smith
> Assignee: Rupert Smith
> Fix For: M2
>
>
> The test:
> ./Ping-Once-Async.sh -c[8] -s[1000] -d1D ackMode=257 pubsub=true destinationCount=10 messageSize=5000 persistent=false transacted=false broker=tcp://10.0.0.1:9000 consAckMode=257 consTransacted=false maxPending=500000 uniqueDests=false -o no_ack_test/ -n NoAckPubSub
> Jams after a while. On every message sent it increments a count, on every message received it decrements. A maximum count limit is set to prevent the test from OOMEing the broker. If messages are lost, and never received, the count will eventually hit its maximum value and jam the test.
> Investigate possible message loss in NO_ACK mode.
> Add a time-out into the test to fail it when this happens.
> Add numbering of messages to the test. Messages should arrive in the order they are sent, so message loss should show up as a gap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-616) Underflow in calculating message pending
size in perftests.
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rupert Smith updated QPID-616:
------------------------------
Fix Version/s: M2.1
Affects Version/s: M2.1
Summary: Underflow in calculating message pending size in perftests. (was: Message Loss in NO_ACK Mode.)
> Underflow in calculating message pending size in perftests.
> -----------------------------------------------------------
>
> Key: QPID-616
> URL: https://issues.apache.org/jira/browse/QPID-616
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client
> Affects Versions: M2, M2.1
> Environment: Java client and broker, M2.
> Reporter: Rupert Smith
> Assignee: Rupert Smith
> Fix For: M2, M2.1
>
>
> The test:
> ./Ping-Once-Async.sh -c[8] -s[1000] -d1D ackMode=257 pubsub=true destinationCount=10 messageSize=5000 persistent=false transacted=false broker=tcp://10.0.0.1:9000 consAckMode=257 consTransacted=false maxPending=500000 uniqueDests=false -o no_ack_test/ -n NoAckPubSub
> Jams after a while. On every message sent it increments a count, on every message received it decrements. A maximum count limit is set to prevent the test from OOMEing the broker. If messages are lost, and never received, the count will eventually hit its maximum value and jam the test.
> Investigate possible message loss in NO_ACK mode.
> Add a time-out into the test to fail it when this happens.
> Add numbering of messages to the test. Messages should arrive in the order they are sent, so message loss should show up as a gap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (QPID-616) Underflow in calculating message
pending size in perftests.
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rupert Smith resolved QPID-616.
-------------------------------
Resolution: Fixed
> Underflow in calculating message pending size in perftests.
> -----------------------------------------------------------
>
> Key: QPID-616
> URL: https://issues.apache.org/jira/browse/QPID-616
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client
> Affects Versions: M2, M2.1
> Environment: Java client and broker, M2.
> Reporter: Rupert Smith
> Assignee: Rupert Smith
> Fix For: M2, M2.1
>
>
> The test:
> ./Ping-Once-Async.sh -c[8] -s[1000] -d1D ackMode=257 pubsub=true destinationCount=10 messageSize=5000 persistent=false transacted=false broker=tcp://10.0.0.1:9000 consAckMode=257 consTransacted=false maxPending=500000 uniqueDests=false -o no_ack_test/ -n NoAckPubSub
> Jams after a while. On every message sent it increments a count, on every message received it decrements. A maximum count limit is set to prevent the test from OOMEing the broker. If messages are lost, and never received, the count will eventually hit its maximum value and jam the test.
> Investigate possible message loss in NO_ACK mode.
> Add a time-out into the test to fail it when this happens.
> Add numbering of messages to the test. Messages should arrive in the order they are sent, so message loss should show up as a gap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.