Re: sender.close() hangs
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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org . 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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: sender.close() hangs
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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: sender.close() hangs
On 06/07/2019 11:50 AM, Gordon Sim wrote: On 06/06/2019 2:33 pm, Jose Alberto Fernandez Parejo wrote: Hello everyone, We are using rabbitmq broker and qpid-cpp last version API to send/receive messages to/from broker with AMQP1.0 Our application using several senders over the same connection and session. When calling to sender.close() procedure application hangs and no error nor trace is shown. We have enable debugging and nothing is seen. Besides, in the server.cpp example provided in qpid-cpp the same problem happens. Anyone knows what it is the problem? Can you get a protocol trace? E.g. set env var QPID_LOG_ENABLE=trace+ when running the client. That will show the interaction with the broker on closing a sender link and hopefully some insight into the problem. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org . Hello, Please find below the protocol trace. Note that the client: Open connection createSession createSender Send Close sender and at this point hangs. We have test that if we make a connection close without closing sender it hangs also. Sorry if message is twice, I think that we have problems with mail server # /tmp/client 2019-06-10 08:19:33 [Messaging] debug Protocol defaults: amqp1.0,amqp0-10 2019-06-10 08:19:33 [Messaging] debug Trying versions amqp1.0, amqp0-10 2019-06-10 08:19:33 [Messaging] debug Driver started 2019-06-10 08:19:33 [Messaging] info Starting connection to amqp:tcp:127.0.0.1:5672 2019-06-10 08:19:33 [Messaging] info Connecting to tcp:127.0.0.1:5672 2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 Connecting ... 2019-06-10 08:19:33 [Client] debug Set TCP_NODELAY 2019-06-10 08:19:33 [System] info Connecting: 127.0.0.1:5672 2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 Connected 2019-06-10 08:19:33 [Messaging] debug wakeupDriver() 2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 Waiting to be authenticated... 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 1 || 0 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 1 || 0 2019-06-10 08:19:33 [Protocol] debug tcp:127.0.0.1:5672 writing protocol header: 1-0 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::encode(65535): 8 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Protocol] debug tcp:127.0.0.1:5672 read protocol header: 1-0 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::decode(8): 8 2019-06-10 08:19:33 [Security] trace Reading SASL frame of size 52 2019-06-10 08:19:33 [Security] trace Reading SASL-MECHANISMS 2019-06-10 08:19:33 [Protocol] debug tcp:127.0.0.1:5672 Received SASL-MECHANISMS(ANONYMOUS PLAIN AMQPLAIN ) 2019-06-10 08:19:33 [Security] debug CyrusSasl::start(ANONYMOUS PLAIN AMQPLAIN ) 2019-06-10 08:19:33 [Security] debug min_ssf: 0, max_ssf: 256 2019-06-10 08:19:33 [Security] debug CyrusSasl::start(ANONYMOUS PLAIN AMQPLAIN ): selected ANONYMOUS response: 'anonymous@stringc4' 2019-06-10 08:19:33 [Security] trace Completed encoding of frame of 62 bytes 2019-06-10 08:19:33 [Protocol] debug tcp:127.0.0.1:5672 Sent SASL-INIT(ANONYMOUS, anonymous@stringc4, 127.0.0.1) 2019-06-10 08:19:33 [Messaging] debug wakeupDriver() 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::decode(52): 52 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 1 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 1 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::encode(65535): 62 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Security] trace Reading SASL frame of size 17 2019-06-10 08:19:33 [Security] trace Reading SASL-OUTCOME 2019-06-10 08:19:33 [Protocol] debug tcp:127.0.0.1:5672 Received SASL-OUTCOME(\x00) 2019-06-10 08:19:33 [Messaging] debug wakeupDriver() 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::decode(17): 17 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Messaging] trace tcp:127.0.0.1:5672 encode(65535) 2019-06-10 08:19:33 [Protocol] trace [c4f5e37c-7575-41df-802d-41877b9bfe06]: -> AMQP 2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 encoded 8 bytes from 65535 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Messaging] trace tcp:127.0.0.1:5672 encode(65535) 2019-06-10 08:19:33 [Security] trace tcp:127.0.0.1:5672 Sasl::canEncode(): 0 || 0 2019-06-10 08:19:33 [Messaging] trace tcp:127.0.0.1:5672 decode(8) 2019-06-10 08:19:33 [Protocol] trace
Re: sender.close() hangs
On 06/06/2019 2:33 pm, Jose Alberto Fernandez Parejo wrote: Hello everyone, We are using rabbitmq broker and qpid-cpp last version API to send/receive messages to/from broker with AMQP1.0 Our application using several senders over the same connection and session. When calling to sender.close() procedure application hangs and no error nor trace is shown. We have enable debugging and nothing is seen. Besides, in the server.cpp example provided in qpid-cpp the same problem happens. Anyone knows what it is the problem? Can you get a protocol trace? E.g. set env var QPID_LOG_ENABLE=trace+ when running the client. That will show the interaction with the broker on closing a sender link and hopefully some insight into the problem. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
sender.close() hangs
Hello everyone, We are using rabbitmq broker and qpid-cpp last version API to send/receive messages to/from broker with AMQP1.0 Our application using several senders over the same connection and session. When calling to sender.close() procedure application hangs and no error nor trace is shown. We have enable debugging and nothing is seen. Besides, in the server.cpp example provided in qpid-cpp the same problem happens. Anyone knows what it is the problem? Thanks in adavance Regards 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: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
