<div dir="ltr">Hey Ray,<div><br></div><div style>I can confirm that this problem at least affects the qpid implementation. I think catching all exceptions and retrying in a backing off manner is great. I have noticed that it seems like we haven't been doing a blanket catch-all for both sql and amqp connections. I'm assuming that was a decision not a mistake, so I'm interested to hear feedback on this also.</div>
<div style><br></div><div style>Anyway, +1 from me on doing what you are suggesting.</div><div style><br></div><div style>-Mike Wilson</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 11:03 AM, Ray Pekowski <span dir="ltr"><<a href="mailto:pekowski@gmail.com" target="_blank">pekowski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I was thinking about the use of RPC consume_in_thread() in the single reply queue changes I made and how the crashing of the created thread would result in RPC call timeout failures in all future attempts to issue RPC calls (not casts).  Probably, the worst part is that the RPC calls would be sent and perhaps successfully executed, but the responses would not be received.  The RPC would timeout.<br>

<br></div><div>There is a similar issue with the consume_in_thread() being done in the RPC dispatcher that receives RPC requests, but in this case the RPCs are not executed.<br></div><div><br></div>I looked into consume_in_thread() and realize that the base thread it creates does not in fact do the equivalent of a catch all (except Exception).  This means some unexpected exception could result in the death of the consumer thread.  I was wondering if we should add an "except Exception" in the consumer infinite loop that perhaps sleeps for a time and goes on.  Of course, we would have to make sure in the same loop an exception for a valid kill of the thread was caught.  Currently that is "except greenlet.GreenletExit".  On the other hand, if the thread died for some unexpected reason, it might just die again for the same reason, but that is why I suggest adding a sleep to the loop.  To prevent a 100% CPU situation.<br>

<br></div><div>At minimum, some check for consumer thread still running should be made before sending an RPC call.<br></div><div><br></div>Maybe I'm reading the code wrong.  If not, this affects all RPC implementations: kombu, qpid and zmq.  For zmq, I think the problem only exists on the server side.<br>

<br></div><div>Any thoughts?<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>Ray<br></font></span></div>
<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>
<br></blockquote></div><br></div>