[jira] [Commented] (AMQ-5413) AMQP test client delivery/redelivery anomoly

["Chuck Rolke (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185786#comment-14185786 ] 

Chuck Rolke commented on AMQ-5413:
----------------------------------

I believe that the broker is mishandling the Flow performative 'drain' flag. Referring to trace http://people.apache.org/~chug/adverb_qpid_send_receive_1/qpid-send-receive_activemq-5.11_nodelay_1.html the following flow exchange happens:
{noformat}
◊  ◊◊  Frame 97  127.0.0.1:38598  -> 127.0.0.1:5672  10.422229 flow [0,0] (0,1000)   (drain=false)
◊  ◊◊  Frame 98  127.0.0.1:38598  -> 127.0.0.1:5672  10.422252 flow [0,0] (0,1000)   (drain=true)
◊  ◊◊  Frame 100  127.0.0.1:38598 <-  127.0.0.1:5672  10.423470 flow [0,0] (1000,0)
◊  ◊◊  Frame 101  127.0.0.1:38598  -> 127.0.0.1:5672  10.423595 flow [0,0] (1000,1000)
◊  ◊◊  Frame 102  127.0.0.1:38598 <-  127.0.0.1:5672  10.423810 flow [0,0] (2000,0)
{noformat}
The client sends two closely spaced flow messages to the broker. They are identical except that the drain flag is false in Frame 97 but true in Frame 98. The broker responds in Frame 100 by advancing the delivery count to 1000 to drain the available credit.  Frames 101 and 102 are a repeat of the flow-with-drain from the client followed by the broker effecting the drain with an advanced delivery count.

The protocol error is that by AMQP 1.0 the sender receiving a flow with drain=true SHOULD send all available messages before advancing the delivery count to effect the drain.

Just a guess here but the broker looks like it starts to form a delivery for the message it has in the queue but can't deliver it because the drain behavior kicked in. That's why when the client finally gets the message it is 'redelivered'.

Since the behavior is marked with SHOULD and not with MUST then the drain behavior is probably acceptable. However, if the drain bypasses available messages then a user might expect that the messages would finally be delivered with Redelivered=false. 

> AMQP test client delivery/redelivery anomoly
> --------------------------------------------
>
>                 Key: AMQ-5413
>                 URL: https://issues.apache.org/jira/browse/AMQ-5413
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: AMQP, Broker
>    Affects Versions: 5.11.0
>         Environment: broker: snapshot apache-activemq-5.11-20141022.222801-124-bin.tar.gz 	
>   Wed Oct 22 22:28:02 UTC 2014
> host: Linux Fedora 19 x64
> clients: Apache Qpid C++ messaging qpid-send qpid-receive (current trunk)
> protocol: AMQP 1.0
>            Reporter: Chuck Rolke
>
> Using Apache Qpid test clients qpid-send and qpid-receive ActiveMQ broker behaves differently from qpidd and I'm wondering if the difference is important.
> The test code command lines are:
> {noformat}
> qpid-send -a "chuck; {create:always}" --connection-options {protocol:amqp1.0} --sequence yes --content-string 0
> qpid-receive -a chuck -m 1 --connection-options "{protocol:amqp1.0}" --print-headers yes
> {noformat}
> When I run the tests against qpidd they send one message and receive one message every time. However against ActiveMQ 5.11 the qpid-receive does not receive the message until one of several conditions:
> * the qpid-receive command also includes "--timeout 1"
> * the qpid-receive command is repeated several, possibly dozens, of times.
> When qpidd broker is running or when activemq is running and --timeout is specified then the qpid-receive output is:
> {noformat}
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options "{protocol:amqp1.0}" --print-headers yes
> Properties: {sn:1, ts:1414177685195174548, x-amqp-first-acquirer:True}
> 0
> {noformat}
> However, activemq running the client twice without the timeout and once with the timeout looks like this:
> {noformat}
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options "{protocol:amqp1.0}" --print-headers yes
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options "{protocol:amqp1.0}" --print-headers yes
> chug@FJELD ~> qpid-receive -a chuck -m 1 --connection-options "{protocol:amqp1.0}" --print-headers yes --timeout 1
> Redelivered: true
> Properties: {sn:1, ts:1414178091185765136, x-amqp-delivery-count:1}
> 0
> {noformat}
> The false receive attempts make the message look like it was already delivered, hence the Redelivered: true, first-acquirer absent and the x-amqp-delivery-count setting.
> Views of the protocol interactions between the brokers and clients are here:
> http://people.apache.org/~chug/adverb_qpid_send_receive_1/
> I ran the tests twice on ActiveMQ with the tcpnodelay option turned on and off but that didn't seem to make any difference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)