Hi,
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?
We added an undocumented 'proton::reconnect_timer' to client options:
proton::reconnect_timer reconnection_info(/*first=*/0,
/*max delay=*/-1,
/*increment=*/500,
/*doubling=*/false,
/*max_retries=*/20,
/*timeout=*/-1);
proton::connection_options client_conn_opts;
client_conn_opts.reconnect(reconnection_info);
c.client_connection_options(client_conn_opts);
connection_ = c.connect(get_url());
// ... elsewhere ...
client_thread_ = std::make_unique<std::thread>([this]()
{
LOGF(logger_, LoggerIF::INFO,
"client thread started using URL %s",
central_conf_->client_url.c_str());
for (;;)
{
try
{
proton::default_container(*client_).run();
LOGF(logger_, LoggerIF::INFO, "client completed");
}
catch (const std::exception& e)
{
LOGF(logger_, LoggerIF::ERROR,
"client completed due to exception: %s", e.what());
}
client_->close();
}
return 0;
});
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.
Thanks,
Jeff
