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
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


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