You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by yonexw <zw...@liquidcapital.com> on 2013/01/30 09:55:00 UTC
connection is detached after receiver is created.
I am using qpid c++ client API to connect to broker with SSL connection.
but after I create the receiver I got session detached and connection
closed, can someone shed some light on this? Apid logs as following:
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionAttachBody: name=3add9a03-3d3d-4d23-bcb9-9b97d174a0d1; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionAttachedBody: name=3add9a03-3d3d-4d23-bcb9-9b97d174a0d1; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCommandPointBody: command-id=0; command-offset=0; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionRequestTimeoutBody: timeout=0; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCommandPointBody: command-id=0; command-offset=0; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{ExecutionSyncBody: }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionTimeoutBody: timeout=0; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,0] }; }]
[Client] debug treating source address as queue:
broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation;{assert:never,
create:never, mode:consume, node:{type:queue}}
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{QueueDeclareBody: queue=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation;
alternate-exchange=; passive=1; arguments={}; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,1] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageSubscribeBody:
queue=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation;
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation; accept-m
[Client] debug treating source address as queue:
broadcast.LCMLO_LCMLOALBBRETEST.Workflow;{assert:never, create:never,
mode:consume, node:{type:queue}}
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{QueueDeclareBody: queue=broadcast.LCMLO_LCMLOALBBRETEST.Workflow;
alternate-exchange=; passive=1; arguments={}; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,3] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageSubscribeBody: queue=broadcast.LCMLO_LCMLOALBBRETEST.Workflow;
destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow; accept-mode=0;
acquire-mod
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageSetFlowModeBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation; flow-mode=0;
}]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageFlowBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation; unit=0;
value=1; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageFlowBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation; unit=1;
value=4294967295; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionFlushBody: completed=1; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ }; timely-reply=1; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[Bbe; channel=1;
{MessageTransferBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation;
accept-mode=0; acquire-mode=0; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[be; channel=1;
header (71 bytes); properties={{MessageProperties: content-length=1073;
app-id=; }{DeliveryProperties: delivery-mode=2; exchange=broadcast;
routing-key=b
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[Ebe; channel=1;
content (1073 bytes) <?xml version="1.0" encoding="UT...]
[Client] debug Delivered {MessageTransferBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation;
accept-mode=0; acquire-mode=0; } header (71 bytes);
properties={{MessageProperties: content-length=1073; app-id=; }{De
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionKnownCompletedBody: commands={ }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageSetFlowModeBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow; flow-mode=0; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageFlowBody: destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow;
unit=0; value=1; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageFlowBody: destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow;
unit=1; value=4294967295; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageFlushBody: destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,11] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageStopBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,12] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageReleaseBody: transfers={ }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageCancelBody:
destination=broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{ExecutionSyncBody: }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,15] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageReleaseBody: transfers={ }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageStopBody: destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,17] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageReleaseBody: transfers={ }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageCancelBody: destination=broadcast.LCMLO_LCMLOALBBRETEST.Workflow; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{ExecutionSyncBody: }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionCompletedBody: commands={ [0,20] }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{MessageReleaseBody: transfers={ }; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionDetachBody: name=3add9a03-3d3d-4d23-bcb9-9b97d174a0d1; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=1;
{SessionDetachedBody: name=3add9a03-3d3d-4d23-bcb9-9b97d174a0d1; code=0; }]
[Security] trace SENT [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=0;
{ConnectionCloseBody: reply-code=200; reply-text=OK; }]
[Security] trace RECV [[33888 192.168.0.1:10170]]: Frame[BEbe; channel=0;
{ConnectionCloseOkBody: }]
[System] debug Exception constructed: Closed by client
--
View this message in context: http://qpid.2158936.n2.nabble.com/connection-is-detached-after-receiver-is-created-tp7587655.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by Gordon Sim <gs...@redhat.com>.
On 01/30/2013 10:47 AM, yonexw wrote:
>
> try
> {
> Receiver rcver = session.createReceiver(addr);
> ......
> }
> catch (const qpid::messaging::NoMessageAvailable& ex)
> {
> // No message, ignore exception and keep working
> print("Ignore no message available exception, and keep working.");
> }
What does 'keep working' mean here? The tray block includes the creation
of the receiver, is there some wider loop? If so is the receiver
supposed to be recreated?
> From our app log, the connection closed before fetch timeout.
What about the other receiver? In the log you can see there was a
timeout because that is when the flush and sync is issued.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by yonexw <zw...@liquidcapital.com>.
try
{
Receiver rcver = session.createReceiver(addr);
......
}
catch (const qpid::messaging::NoMessageAvailable& ex)
{
// No message, ignore exception and keep working
print("Ignore no message available exception, and keep working.");
}
>From our app log, the connection closed before fetch timeout.
--
View this message in context: http://qpid.2158936.n2.nabble.com/connection-is-detached-after-receiver-is-created-tp7587655p7587668.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by Gordon Sim <gs...@redhat.com>.
On 01/30/2013 10:34 AM, yonexw wrote:
> Thanks Gordon, I turn off the sending thread, it is still the same.
(Does the sending thread also create another receiver? There are two
concurrent receivers in the log you posted).
> I catch the exception qpid::messaging::NoMessageAvailable and just ignore
> it.
Where do you do that? In the code snippet from earlier:
On 01/30/2013 09:22 AM, yonexw wrote:> related my app code for reading
broadcast as following:
> try
> {
> Receiver rcver = session.createReceiver(addr);
> while(!stopFlag)
> {
> Message msg = rcver .fetch(Duration::SECOND * 10);
> //ProcessBroadcast(msg); message processing
> session.acknowledge();
> }
> }
> catch() .....
If you catch the NoMessageAvailable down here then what happens next?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by yonexw <zw...@liquidcapital.com>.
Thanks Gordon, I turn off the sending thread, it is still the same.
I catch the exception qpid::messaging::NoMessageAvailable and just ignore
it.
--
View this message in context: http://qpid.2158936.n2.nabble.com/connection-is-detached-after-receiver-is-created-tp7587655p7587666.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by Gordon Sim <gs...@redhat.com>.
On 01/30/2013 10:23 AM, yonexw wrote:
> correct, I have two separated thread for sending and receiving.
> Can not the session support multiple thread?
It can, but I suspect what might be happening here is that one thread is
triggering the close of the session. What happens for example if a
message is not received in the specified time?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by yonexw <zw...@liquidcapital.com>.
correct, I have two separated thread for sending and receiving.
Can not the session support multiple thread?
--
View this message in context: http://qpid.2158936.n2.nabble.com/connection-is-detached-after-receiver-is-created-tp7587655p7587664.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by Gordon Sim <gs...@redhat.com>.
On 01/30/2013 09:22 AM, yonexw wrote:
> related my app code for reading broadcast as following:
> try
> {
> Receiver rcver = session.createReceiver(addr);
> while(!stopFlag)
> {
> Message msg = rcver .fetch(Duration::SECOND * 10);
> //ProcessBroadcast(msg); message processing
> session.acknowledge();
> }
> }
> catch() .....
It looks from the log like you using the same session in another thread
as well?
There are two subscriptions, for
broadcast.LCMLO_LCMLOALBBRETEST.TradeConfirmation and
broadcast.LCMLO_LCMLOALBBRETEST.Workflow.
One message is received from the TradeConfirmation queue then the client
cancels each subscription and detaches. (i.e. it is not the broker that
is initiating the detach for any reason).
Is one or other thread timing out or hitting an exception that triggers
some cleanup?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by yonexw <zw...@liquidcapital.com>.
from the bottom line logs, it seems session detached after sync. In what
scenario client will detach session after session sync?
--
View this message in context: http://qpid.2158936.n2.nabble.com/connection-is-detached-after-receiver-is-created-tp7587655p7587662.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: connection is detached after receiver is created.
Posted by yonexw <zw...@liquidcapital.com>.
related my app code for reading broadcast as following:
try
{
Receiver rcver = session.createReceiver(addr);
while(!stopFlag)
{
Message msg = rcver .fetch(Duration::SECOND * 10);
//ProcessBroadcast(msg); message processing
session.acknowledge();
}
}
catch() .....
--
View this message in context: http://qpid.2158936.n2.nabble.com/connection-is-detached-after-receiver-is-created-tp7587655p7587661.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org