On 10/18/18 9:59 AM, Ken Giusti wrote:
Hi Renat,
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.
If we are to leave it in we'd really want to discourage its use.
Since it appears the actual executor code lives in futurist, would it be
possible to remove the entrypoint for blocking from oslo.messaging and
have mistral just pull it in with their setup.cfg? Seems like they
should be able to add something like:
oslo.messaging.executors =
blocking = futurist:SynchronousExecutor
to their setup.cfg to keep it available to them even if we drop it from
oslo.messaging itself. That seems like a good way to strongly discourage
use of it while still making it available to projects that are really
sure they want it.
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.
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).
Other opinions so we can come to a consensus?
On Thu, Oct 18, 2018 at 3:24 AM Renat Akhmerov <renat.akhme...@gmail.com
<mailto:renat.akhme...@gmail.com>> wrote:
Hi Oslo Team,
Can we retain “blocking” executor for now in Oslo Messaging?
Some background..
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].
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 *seems*
to work with it but surprisingly performance is much worse.
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.
[1] https://bugs.launchpad.net/mistral/+bug/1696469
Thanks
Renat Akhmerov
@Nokia
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ken Giusti (kgiu...@gmail.com <mailto:kgiu...@gmail.com>)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
