qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Donner <jdon...@morphodetection.com>
Subject RE: Slow-starting queue visibility and handling it
Date Mon, 16 Jan 2017 20:50:50 GMT
Doh. It turned out we had a mismatched queue name. Sorry ...! And thanks. 

Jeff
________________________________________
From: Gordon Sim [gsim@redhat.com]
Sent: Monday, January 16, 2017 1:55 AM
To: users@qpid.apache.org
Subject: Re: Slow-starting queue visibility and handling it

On 14/01/17 02:43, Jeff Donner wrote:
>   We're using proton 14, and qpidd 1.35. We probably have bad routing at one spot from
a proton client to a qpidd broker on another machine, and the client is slow to see the queue
(it fails out with "amqp:no-found"), even though the broker has been running steadily and
the ping time is ~500ms. qpid-tool is also slow to see anything - you can type list for 5
seconds before you see any queues (it takes about 5 seconds even run locally, though it can
take much longer run remotely). We presume something similar is happening to our proton client
(though it looks for a specific queue, so there should be no time spent collecting metainfo).
>
> The client fails instantly - if the client were failing to connect at the TCP level wouldn't
TCP just wait for a few seconds?

[...]

> But it doesn't seem to prevent the initial failing. Is the reconnect_timer just for /dropped/
connections?
>
> Is there any mechanism to cope with slow connections? This code all works fine on better-connected
machines.

Usually, the amqp:not-found error  is sent back by the broker when the
client tries to attach to a queue that doesn't exist. How is the queue
in question being created?

I don't *think* this has anything to do with 'slowness', if it is indeed
the broker that is sending back that error, as I think it must be. Is it
possible it is somehow connecting to the wrong broker?

You say 'initial failing', does that mean that if it retries it usually
succeeds?

Can you get a protocl trace from the failing client (Run with env var
PN_TRACE_FRM=1)? Or a wireshark trace?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message