You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jose Alberto Fernandez Parejo <ja...@indra.es> on 2019/06/06 13:33:19 UTC
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: sender.close() hangs
Posted by Jose Alberto Fernandez Parejo <ja...@indra.es>.
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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: sender.close() hangs
Posted by Gordon Sim <gs...@redhat.com>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: sender.close() hangs
Posted by Jose Alberto Fernandez Parejo <ja...@indra.es>.
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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@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
[c4f5e37c-7575-41df-802d-41877b9bfe06]: <- AMQP
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 8 bytes
from 8
2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 Authenticated
2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 Opening...
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
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]: 0 -> @open(16)
[container-id="c4f5e37c-7575-41df-802d-41877b9bfe06", channel-max=32767,
properties={:"qpid.client_process"=:client, :"qpid.client_pid"=62307,
:"qpid.client_ppid"=65119}]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 encoded 151 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(277)
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @open(16)
[container-id="rabbit@stringc4", channel-max=32767, idle-time-out=60000,
properties={:"cluster_name"="rabbit@stringc4", :copyright="Copyright (C)
2007-2018 Pivotal Software, Inc.", :information="Licensed under the MPL.
See http://www.rabbitmq.com/", :platform="Erlang/OTP 21.2.2",
:product="RabbitMQ", :version="3.7.10"}]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 277 bytes
from 277
2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 AMQP 1.0
idle-timeout set: local=0 remote=60000
2019-06-10 08:19:33 [Messaging] debug tcp:127.0.0.1:5672 Opened
2019-06-10 08:19:33 [Messaging] info Connected to tcp:127.0.0.1:5672
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
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]: 0 -> @begin(17)
[next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 encoded 33 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(36)
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @begin(17)
[remote-channel=0, next-outgoing-id=0, incoming-window=65535,
outgoing-window=65535, handle-max=4294967295]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 36 bytes
from 36
2019-06-10 08:19:33 [Messaging] debug Link attach sent for 0x1668c50,
state=10
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
2019-06-10 08:19:33 [Messaging] debug Waiting for confirmation of link
attach for 0x1668c50, state=10...
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]: 0 -> @attach(18)
[name="control_queue_4d16b47a-591c-44d5-a662-69508bd28be0", handle=0,
role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="control_queue", durable=0, timeout=0, dynamic=false],
target=@target(41) [address="control_queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0, max-message-size=0]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 encoded 151 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(174)
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @attach(18)
[name="control_queue_4d16b47a-591c-44d5-a662-69508bd28be0", handle=0,
role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="control_queue", durable=0, timeout=0, dynamic=false],
target=@target(41) [address="control_queue", durable=0, timeout=0,
dynamic=false]]
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @flow(19)
[next-incoming-id=0, incoming-window=65535, next-outgoing-id=0,
outgoing-window=65535, handle=0, link-credit=65536, drain=false,
echo=false]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 174 bytes
from 174
2019-06-10 08:19:33 [Messaging] debug Attach succeeded to control_queue
2019-06-10 08:19:33 [Messaging] debug Link attach sent for 0x1667200,
state=10
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
2019-06-10 08:19:33 [Messaging] debug Waiting for confirmation of link
attach for 0x1667200, state=10...
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]: 0 -> @attach(18)
[name="response_queue_25dfdbb5-d4e8-4eda-a1b0-d4348910f1ba", handle=1,
role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="response_queue", durable=0, timeout=0, dynamic=false],
target=@target(41) [address="response_queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0, max-message-size=0]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 encoded 154 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(186)
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @attach(18)
[name="response_queue_25dfdbb5-d4e8-4eda-a1b0-d4348910f1ba", handle=1,
role=false, snd-settle-mode=0, rcv-settle-mode=0, source=@source(40)
[address="response_queue", durable=0, timeout=0, dynamic=false,
default-outcome=@released(38) [],
outcomes=@PN_SYMBOL[:"amqp:accepted:list", :"amqp:rejected:list",
:"amqp:released:list"]], initial-delivery-count=0]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 186 bytes
from 186
2019-06-10 08:19:33 [Messaging] debug Attach succeeded from
response_queue
2019-06-10 08:19:33 [Messaging] debug Sending message, buffer is 97
bytes
2019-06-10 08:19:33 [Messaging] debug Trimming buffer from 97 to 86
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 -> @transfer(20) [handle=0,
delivery-id=0, delivery-tag=b"\x00\x00\x00\x00", message-format=0] (86)
"\x00Sp\xc0\x04\x02BP\x00\x00Ss\xd0\x00\x00\x00\x18\x00\x00\x00\x05@@@@\xa1\x0eresponse_queue\x00St\xc1\x01\x00\x00Sw\xa0"Twas
brillig, and the slithy toves"
2019-06-10 08:19:33 [Messaging] debug Sending message, buffer is 95
bytes
2019-06-10 08:19:33 [Messaging] debug Trimming buffer from 95 to 84
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 -> @transfer(20) [handle=0,
delivery-id=1, delivery-tag=b"\x01\x00\x00\x00", message-format=0] (84)
"\x00Sp\xc0\x04\x02BP\x00\x00Ss\xd0\x00\x00\x00\x18\x00\x00\x00\x05@@@@\xa1\x0eresponse_queue\x00St\xc1\x01\x00\x00Sw\xa0
Did gire and gymble in the wabe."
2019-06-10 08:19:33 [Messaging] debug Sending message, buffer is 93
bytes
2019-06-10 08:19:33 [Messaging] debug Trimming buffer from 93 to 82
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 -> @transfer(20) [handle=0,
delivery-id=2, delivery-tag=b"\x02\x00\x00\x00", message-format=0] (82)
"\x00Sp\xc0\x04\x02BP\x00\x00Ss\xd0\x00\x00\x00\x18\x00\x00\x00\x05@@@@\xa1\x0eresponse_queue\x00St\xc1\x01\x00\x00Sw\xa0\x1eAll
mimsy were the borogroves,"
2019-06-10 08:19:33 [Messaging] debug Sending message, buffer is 91
bytes
2019-06-10 08:19:33 [Messaging] debug Trimming buffer from 91 to 80
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
2019-06-10 08:19:33 [Messaging] debug wakeupDriver()
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]: 0 -> @transfer(20) [handle=0,
delivery-id=3, delivery-tag=b"\x03\x00\x00\x00", message-format=0] (80)
"\x00Sp\xc0\x04\x02BP\x00\x00Ss\xd0\x00\x00\x00\x18\x00\x00\x00\x05@@@@\xa1\x0eresponse_queue\x00St\xc1\x01\x00\x00Sw\xa0\x1cAnd
the mome raths outgrabe."
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 -> @detach(22) [handle=0,
closed=true]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 encoded 483 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(17)
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @detach(22) [handle=0]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 17 bytes
from 17
2019-06-10 08:19:33 [Messaging] trace tcp:127.0.0.1:5672 decode(24)
2019-06-10 08:19:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 <- @disposition(21)
[role=true, first=0, last=3, settled=true, state=@accepted(36) []]
2019-06-10 08:19:33 [Network] debug tcp:127.0.0.1:5672 decoded 24 bytes
from 24
2019-06-10 08:20:03 [Messaging] debug ConnectionTickerTask fired
2019-06-10 08:20:03 [Messaging] debug wakeupDriver()
2019-06-10 08:20:03 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:03 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 -> (EMPTY FRAME)
2019-06-10 08:20:03 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:03 [Messaging] trace tcp:127.0.0.1:5672 encode(65535)
2019-06-10 08:20:03 [Network] debug tcp:127.0.0.1:5672 encoded 8 bytes
from 65535
2019-06-10 08:20:03 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:03 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:03 [Messaging] trace tcp:127.0.0.1:5672 encode(65535)
2019-06-10 08:20:03 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:33 [Messaging] debug ConnectionTickerTask fired
2019-06-10 08:20:33 [Messaging] debug wakeupDriver()
2019-06-10 08:20:33 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:33 [Protocol] trace
[c4f5e37c-7575-41df-802d-41877b9bfe06]: 0 -> (EMPTY FRAME)
2019-06-10 08:20:33 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:33 [Messaging] trace tcp:127.0.0.1:5672 encode(65535)
2019-06-10 08:20:33 [Network] debug tcp:127.0.0.1:5672 encoded 8 bytes
from 65535
2019-06-10 08:20:33 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:33 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
2019-06-10 08:20:33 [Messaging] trace tcp:127.0.0.1:5672 encode(65535)
2019-06-10 08:20:33 [Security] trace tcp:127.0.0.1:5672
Sasl::canEncode(): 0 || 0
________________________________
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: sender.close() hangs
Posted by Gordon Sim <gs...@redhat.com>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org