Hide Forgot
Created attachment 482782 [details] zero capacity with flow control reproducer Description of problem: We are having one queue with flow control count set (1msg - stop; 1msg - resume). Then client(modified qpid-send) with "sender's capacity" = 0 sends 10messages. First message should pass. Then flowStopped should switch to "True". And sender can possibly wait until flowStopped changes its state back to "False". Instead of that you'll find 2msgs on queue in total but expected value is only one message on queue. Version-Release number of selected component (if applicable): #rpm -qa | grep qpid | sort -u python-qpid-0.9.1073306-1.el5 qpid-cpp-client-0.9.1073306-1.el5 qpid-cpp-client-devel-0.9.1073306-1.el5 qpid-cpp-client-devel-docs-0.9.1073306-1.el5 qpid-cpp-client-ssl-0.9.1073306-1.el5 qpid-cpp-server-0.9.1073306-1.el5 qpid-cpp-server-cluster-0.9.1073306-1.el5 qpid-cpp-server-devel-0.9.1073306-1.el5 qpid-cpp-server-ssl-0.9.1073306-1.el5 qpid-cpp-server-store-0.9.1073306-1.el5 qpid-cpp-server-xml-0.9.1073306-1.el5 qpid-java-client-0.9.1073306-1.el5 qpid-java-common-0.9.1073306-1.el5 qpid-java-example-0.9.1073306-1.el5 qpid-tools-0.9.1073306-1.el5 rh-qpid-cpp-tests-0.9.1073306-1.el5 How reproducible: 100% Steps to Reproduce: 1. compile attached qpid-send 2. run attached shell script Actual results: 2 messages on queue Expected results: 1 message on queue Additional info:
This behaviour is working as designed: The stop limit must be -crossed- in order for flow control to be activated. If the stop limit is 1, then the second message will be the first message that is flow controlled. For example, if your stop limit is 100, then you can send 100 messages (capacity=0) without activating flow control. Flow control will be enacted on the next message - 101st. If capacity is zero, then that 101st message will cause the sender to block. The same is true with the resume limit: it must be crossed [drop -below-] before flow control is deactivated. In this case, the queue must reach 0 messages. See https://docspace.corp.redhat.com/docs/DOC-59418 for more detail.
now i see that it makes no sense to use capacity = "0" as it's the same as capacity = "1" Also for 2=< capacity < 10 I observed that it works, but i was unsure why for capacity >>= 10 in (300 runs) i'm observing msgDepth = ( flow-stop-count + capacity ) but for 2 =< capacity < 10 it's in 99% of cases msgDepth < ( flow-stop-count + capacity ) and all of above agrees with https://docspace.corp.redhat.com/docs/DOC-59418 --> NOT A BUG