Alan Conway created ACTIVEMQ6-46:
------------------------------------
Summary: AMQP interop: Active broker does not respect the "drain"
flag.
Key: ACTIVEMQ6-46
URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-46
Project: Apache ActiveMQ 6
Issue Type: Bug
Affects Versions: 6.0.0
Reporter: Alan Conway
The drain flag on the AMQP flow performative allows a client to request
confirmation that it has received the last available message that it has credit
to receive.
To reproduce using the qpid-send, qpid-receive clients from
http://svn.apache.org/repos/asf/qpid/trunk/qpid/. Create a JMS queue 'foo' on
the active broker then run:
$ qpid-send -a jms.queue.foo -b localhost:5455 --content-string XXX
--connection-options='{protocol:amqp1.0}'
$ qpid-receive -a jms.queue.foo -b localhost:5455
--connection-options='{protocol:amqp1.0}' --log-enable trace+:Protocol
qpid-receive hangs, the last line of output is:
2014-11-24 15:15:46 [Protocol] trace [58e8ee08-0f33-426b-b77a-450f7c3d976c]: 0
-> @flow(19) [next-incoming-id=2, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=1,
link-credit=1, drain=true]
This shows that qpid-receive sent a flow with drain=true but never received a
response.
Why is this important? Without the drain flag it is impossible for a client to
implement the simple behavior "get the next message" correctly. The flow
response tells the client immediately "there are no more messages available for
you". Without it the client can only use a timeout which is unreliable (if too
short the client may give up while the message is in flight) and inefficient
(if too long the client will wait needlessly for messages that the broker knows
are not presently available)
The spec 2.6.7 is a little ambiguous about whether this is a SHOULD or a MUST
behavior but without it it is impossible to implement the use cases described
in the following section.
AMQP 1.0 specification 2.7.6
drain
The drain flag indicates how the sender SHOULD behave when insufficient
messages are available to consume the current link-credit. If set, the sender
will (after sending all available messages) advance the delivery-count as much
as possible, consuming all link-credit, and send the flow state to the
receiver. Only the receiver can independently modify this field. The sender's
value is always the last known value indicated by the receiver.
If the link-credit is less than or equal to zero, i.e., the delivery-count is
the same as or greater than the delivery-limit, a sender MUST NOT send more
messages. If the link-credit is reduced by the receiver when transfers are
in-flight, the receiver MAY either handle the excess messages normally or
detach the link with a transfer-limit-exceeded error code.
Figure 2.40: Flow Control
+----------+ +----------+
| Sender |---------------transfer------------>| Receiver |
+----------+ +----------+
\ / <----------------flow--------------- \ /
+------+ +------+
|
|
|
if link-credit <= 0 then pause
If the sender's drain flag is set and there are no available messages, the
sender MUST advance its delivery-count until link-credit is zero, and send its
updated flow state to the receiver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
