The topic exchange is what causes the behavior I noted. If no one is listening on a topic then it doesn't have a route, therefore throw it away with no error. I'm not familiar with notifier, but if it addresses a node topic then it should work just as well with a node queue.<div>
<br></div><div>I will do some more research into what expectations we have around our communication, but I think at least I am going to try to convert our installation to use queues for node communication and see how it goes. I'll probably have something interesting to say about it in a few days :-).</div>
<div><div><br></div><div>Mike Wilson</div><div>Bluehost.com</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 20, 2012 at 8:12 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/20/2012 12:23 AM, Mike Wilson wrote:<br>
> Hey folks,<br>
><br>
> I've been spending some time with qpid recently investigating a bug<br>
> where compute nodes will randomly loose their binding to their<br>
> compute.hostname topics. When this happens, starting new instances,<br>
> deleting and lots of other functionality which is addressed directly to<br>
> the compute node topic silently fail. Anything that is a "cast" instead<br>
> of a "call" just fails, no errors, no logging, etc. This is because the<br>
> message goes to the exchange but since there is no one listening on the<br>
> compute topic it is silently dropped. Apparently there are ways to deal<br>
> with this setting up a DLQ, also the AMQP spec is built to error out<br>
> when this happens if certain flags are set, see the following for more info:<br>
><br>
> <a href="http://qpid.2158936.n2.nabble.com/How-to-know-when-a-message-could-not-be-enqueued-td3751016.html#a3751626" target="_blank">http://qpid.2158936.n2.nabble.com/How-to-know-when-a-message-could-not-be-enqueued-td3751016.html#a3751626</a><br>

><br>
> In any case, I'm still not quite set on how I will handle this, I'm<br>
> leaning towards implementing the discard-unroutable property in qpid and<br>
> handling the exception in the sender. But I'm still not sure that is the<br>
> best way to go about it. I'm considering using queues as an alternative<br>
> to communicate with nodes.  They are fairly persistent so if there isn't<br>
> a receiver on the line when we send the message they could pick it up<br>
> later. I'm looking for some feedback from the community on this as I<br>
> would like whatever work I'm doing to make it upstream. Thx in advance.<br>
<br>
</div></div>We should start by defining what behavior we want.  I agree with what<br>
you say here at the end.  Ideally when a message is sent to 'compute' or<br>
'compute.<node>' but nothing is currently listening, we want that<br>
message to be queued up and waiting for a compute node to come back<br>
alive and handle it.  (We should be setting a TTL on all messages to<br>
ensure that they don't stay in a queue for forever, but we're not doing<br>
that yet.)<br>
<br>
Is the fact that it's a topic exchange messing this up?  AFAIK, nothing<br>
makes use of the fact that these are topic exchanges, except maybe<br>
notifications (rpc_notifier), so we need to watch out for that.<br>
<br>
For the 'compute' and 'compute.<node>' style queues used by all of the<br>
services, I believe queues on a direct exchange would work just fine for<br>
the semantics we care about.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>