[
https://issues.apache.org/jira/browse/ARTEMIS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14605552#comment-14605552
]
Alan Conway commented on ARTEMIS-46:
------------------------------------
Qpid uses proton internally so "in principal" the reproducer is already using
proton :) In practice I don't have a simpler reproducer for it. I don't know if
any of the existing java clients rely on drain so you may have to hack
something yourself. You could try modifying a java receiver to send "flow" with
drain=true and see if you fail to get the expected final flow with credit=0
from the sender when the queue runs dry. I can't be sure that will do it, there
may be some more detailed sequence of events caused by the qpid client that is
needed to trigger the bug. In that case you could use wireshark or
--debug=trace+:Protocol on the qpid client to look at the frames exchanged and
see what else in there might be relevant.
> AMQP interop: Active broker does not respect the "drain" flag.
> --------------------------------------------------------------
>
> Key: ARTEMIS-46
> URL: https://issues.apache.org/jira/browse/ARTEMIS-46
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
> Affects Versions: 1.0.0
> Reporter: Alan Conway
> Fix For: 1.0.1
>
>
> 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)
