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: [email protected]
For additional commands, e-mail: [email protected]
