[
https://issues.apache.org/jira/browse/ACTIVEMQ6-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226704#comment-14226704
]
Alan Conway commented on ACTIVEMQ6-46:
--------------------------------------
See also AMQ-5453
> 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)
