<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Have you tried to look at the RabbitMQ
      web interface to see what could be stuck ?<br>
      Activating it is quite straightforward, as per Ops Guide :<br>
<a class="moz-txt-link-freetext" href="http://docs.openstack.org/trunk/openstack-ops/content/logging_monitoring.html#rabbitmq">http://docs.openstack.org/trunk/openstack-ops/content/logging_monitoring.html#rabbitmq</a><br>
      <br>
      -Sylvain<br>
      <br>
      <br>
      Le 12/04/2013 17:48, Lowery, Mathew a écrit :<br>
    </div>
    <blockquote
cite="mid:D5C018CAC77E514BA572D79E860DF31C28648FB8@DEN-EXDDA-S12.corp.ebay.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>
        <div>Hi all,</div>
        <div><br>
        </div>
        <div>I am using OpenStack Folsom with nova-network.  In the logs
          I observed some RPC call timeouts during
          associate_floating_ip.  I assume the timeout is actually a
          timeout experienced by RabbitMQ when trying to push the
          associate_floating_ip message to a chosen consumer and not a
          timeout from nova.network.API when trying to publish the
          associate_floating_ip message in the first place.  Could this
          be possible?  If so, how can I tell what consumer RabbitMQ
          chose (i.e. the "down" consumer)?</div>
        <div><br>
        </div>
        <div>Furthermore, I'm seeing multiple thousands of
          exchanges (associate_floating_ip was called a lot) with UUIDs
          as their names.  Is it possible that these exchanges were
          created to receive responses from the down consumer?  Who is
          responsible for cleaning these exchanges up?  I do see an
          "auto-delete" flag set to true.</div>
        <div><br>
        </div>
        <div>Finally, it appears that when an RPC call times out, the
          original message, at least is some cases like
          'network.hostname' queue, is left in place to be consumed when
          a consumer is available.  This seems like an odd design--if I
          take corrective action in response to an RPC timeout, I don't
          think I want that message processed ever.</div>
        <div><br>
        </div>
        <div>I am somewhat new to message queues so feel free to simply
          share links that might explain some of these observations.</div>
        <div><br>
        </div>
        <div>Thanks in advance.</div>
        <div>Mat</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to     : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help   : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>