<div dir="ltr"><div>Hi Renat,</div><div><br></div><div>The biggest issue with the blocking executor (IMHO) is that it blocks the protocol I/O while  RPC processing is in progress.  This increases the likelihood that protocol processing will not get done in a timely manner and things start to fail in weird ways.  These failures are timing related and are typically hard to reproduce or root-cause.   This isn't something we can fix as blocking is the nature of the executor.</div><div><br></div><div>If we are to leave it in we'd really want to discourage its use.</div><div><br></div><div>However I'm ok with leaving it available if the policy for using blocking is 'use at your own risk', meaning that bug reports may have to be marked 'won't fix' if we have reason to believe that blocking is at fault.  That implies removing 'blocking' as the default executor value in the API and having applications explicitly choose it.  And we keep the deprecation warning.<br></div><div><br></div><div>We could perhaps implement time duration checks around the executor callout and log a warning if the executor blocked for an extended amount of time (extended=TBD). <br></div><div><br></div><div>Other opinions so we can come to a consensus?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov <<a href="mailto:renat.akhmerov@gmail.com">renat.akhmerov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div name="messageBodySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif">Hi Oslo Team,
<div><br></div>
<div>Can we retain “blocking” executor for now in Oslo Messaging?</div>
<div><br></div>
<div><br></div>
<div>Some background..</div>
<div><br></div>
<div>For a while we had to use Oslo Messaging with “blocking” executor in Mistral because of incompatibility of MySQL driver with green threads when choosing “eventlet” executor. Under certain conditions we would get deadlocks between green threads. Some time ago we switched to using PyMysql driver which is eventlet friendly and did a number of tests that showed that we could safely switch to “eventlet” executor (with that driver) so we introduced a new option in Mistral where we could choose an executor in Oslo Messaging. The corresponding bug is [1].</div>
<div><br></div>
<div>The issue is that we recently found that not everything actually works as expected when using combination PyMysql + “eventlet” executor. We also tried “threading” executor and the system <b>seems</b> to work with it but surprisingly performance is much worse.</div>
<div><br></div>
<div>Given all of that we’d like to ask Oslo Team not to remove “blocking” executor for now completely, if that’s possible. We have a strong motivation to switch to “eventlet” for other reasons (parallelism => better performance etc.) but seems like we need some time to make it smoothly.</div>
<div><br></div>
<div><br></div>
<div>[1] <a href="https://bugs.launchpad.net/mistral/+bug/1696469" target="_blank">https://bugs.launchpad.net/mistral/+bug/1696469</a><br></div>
<div><br></div>
</div>
<div name="messageSignatureSection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><br>
Thanks<br>
<br>
Renat Akhmerov<br>
@Nokia</div>
</div>

__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Ken Giusti  (<a href="mailto:kgiusti@gmail.com" target="_blank">kgiusti@gmail.com</a>)</div>