I ran the server example against rabbitmq (with a modified client to get
around the lack of support for dynamic addresses). It looks like the
issue is that rabbit responds to a detach with close=true by sending a
detach without setting the close.
The qpid::messaging client uses proton and currently relies on the
endpoint state of the link to determine that it is closed. When
receiving a detach with close not set (which is equivalent to
close=false), there is no way that I can see to determine that this has
happened by querying the proton object. (A PN_LINK_REMOTE_DETACH event
would be generated, but events aren't used in qpid::messaging at present
as they did not exist when it was first written).
I think the rabbitmq-server is not doing the expected thing here. From
2.6.6 in AMQP 1.0 spec:
A peer closes a link by sending the detach frame with the
handle for the specified link, and the closed flag set to
true. The partner will destroy the corresponding link
endpoint, and reply with its own detach frame with the
closed flag set to true.[1]
However I do also think that proton should have a way of determining
that a given link is not attached on the remote side, which it currently
does not (apart from an event). There is already a JIRA for this from
some time back: https://issues.apache.org/jira/browse/PROTON-773
If that were fixed then the qpid::messaging client could be fixed to not
hang in this case even though the server is not sending the detach with
close=true as would be expected.
I'd recommend raising an issue against the 1.0 plugin for rabbitmq. My
guess is it should be a simple fix there. I will see if I can propose
(or get anyone else to propose) a change to proton to allow the detached
(but not closed) state to be determined by some request.
[1] It also says:
Note that one peer MAY send a closing detach while its
partner is sending a non-closing detach. In this case,
the partner MUST signal that it has closed the link by
reattaching and then sending a closing detach.
Though that isn't really the case here as it is clear the server is
responding to the detach from the client rather than deliberatiely
initiating a non-closing detach itself.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
