qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Donner <jdon...@morphodetection.com>
Subject Slow-starting queue visibility and handling it
Date Sat, 14 Jan 2017 02:43:09 GMT

  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,

    proton::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",
      for (;;)
          LOGF(logger_, LoggerIF::INFO, "client completed");
        catch (const std::exception& e)
          LOGF(logger_, LoggerIF::ERROR,
               "client completed due to exception: %s", e.what());
      return 0;

But it doesn't seem to prevent the initial failing. Is the reconnect_timer just for /dropped/

Is there any mechanism to cope with slow connections? This code all works fine on better-connected


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message