On 06/11/2019 01:00 PM, Gordon Sim wrote:
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]
.
Thank you so much for the support.
We have asked to rabbitmq support and we would send to qpid list the
posible solution.
Please Gordon inform us with any update of your propose to change to
proton to allow the detached. In any case we will also check the issue
in JIRA PROTON-773
Thanks again.
________________________________
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario o destinatarios. Si no es vd. el destinatario indicado, queda
notificado que la lectura, utilización, divulgación y/o copia sin autorización
está prohibida en virtud de la legislación vigente. En el caso de haber
recibido este correo electrónico por error, se ruega notificar inmediatamente
esta circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.
This email and any file attached to it (when applicable) contain(s)
confidential information that is exclusively addressed to its recipient(s). If
you are not the indicated recipient, you are informed that reading, using,
disseminating and/or copying it without authorisation is forbidden in
accordance with the legislation in effect. If you have received this email by
mistake, please immediately notify the sender of the situation by resending it
to their email address.
Avoid printing this message if it is not absolutely necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
