[
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)
