Remove six, the python 2/3 compatibility library. It's not needed
anymore since the repo is python3 only.
Remove a now unneeded hacking test.
Change-Id: I40522c4accb4aaf8115d11fee8b081e2d991cb4d
The blocking executor has been deprecated in Pike and marked for removal
in Rocky, but some user like Mistral asked us to wait before. We decided
to remove this executor for Train or next cycle, now we are in the
Ussuri and after some researchs on usage I think we can go ahead.
This patch drop the deprecation warnings, related unit tests and
set the server with the threading executor is the default executor.
Change-Id: If07bab61ee2b148658b88be98b12f8539f274efe
Closes-Bug: #1715141
Log messages are no longer being translated. This removes all use of
the _LE, _LI, and _LW translation markers to simplify logging and to
avoid confusion with new contributions.
Change-Id: I9ddb6595fc52e46ed8844e39d2fa71029c90b65c
Closes-Bug: #1674567
We recently move ack/requeue of messages in main/polling thread
of rabbitmq drivers. And break the blocking executor.
This one is not tested by any tests and now deprecated.
This change workaround the issue until we completely remove the
blocking executor.
Change-Id: Id479100f6ff364cf67a199e9b70f9f0c7bf7e1a9
Closes-bug: #1694728
Using blocking executor is not recommended for application. But it looks
like some use it just because it's the default and are not aware their
should change it despite of documentation and logging message.
Choosing the application threading model is an important step
of an application.
This change deprecates it, in the future we will just make executor
mandatory. This will ensure that application make a choice.
Also this will reduce headache of oslo.messaging developers to
make the driver code working in a sync and async.
And to finish test coverage of blocking executor is 0%...
This rework some tests to remove logging.captureWarnings() that can
catch unwanted warning of other tests. Tests mocks warning instead.
Related-bug: #694728
Change-Id: Ic67164d12e7a9bed76d6e64ca2ced12e3984ff5f
* add application scenario to help of config option
'executor_thread_pool_size'
* Move eventlet patched checking to constructor
Change-Id: I9dc7c993c8947b51952365cc5e7b6f2daae6bb70
oslo.messaging supports three types of executors: blocking, eventlet
and threading, so it's good to list all of them in docstring.
Change-Id: Ief14d54b5f029cf3e9c79334e405dca5cf2dc13d
1) Add MessageHandler base interface for on_incoming_callback replacement
2) Move message_handler parameter form Listener's __init__() to start()
3) Remove wait method from listener
Change-Id: Id414446817e3d2ff67b815074d042a9ce637ec24
Current Listener interface has poll() method which return messages
To use it we need have poller thread which is located in MessageHandlerServer
But my investigations of existing driver's code shows that some implemetations have
its own thread inside for processing connection event loop. This event loop received
messages and store in queue object. And then our poller's thread reads this queue
This situation can be improved. we can remove poller's thread, remove queue object
and just call on_message server's callback from connection eventloop thread
This path provide posibility to do this for one of drivers and leave as is other drivers
Change-Id: I3e3d4369d8fdadcecf079d10af58b1e4f5616047
Dispatcher should be responsible for routing message to the
callback method of endpoint object and returning result back to the
server only. But now it is also responsible for sending reply,
ack/reque messages etc.
Also this patch makes small improvements:
1) Notification dispatcher now requeue message if endpoint raises exception
2) unstable behaviour of test_mask_passwords test is fixed
Change-Id: I5f23e23644e90919cb67f81fc306ee85c5e09974
Now we have situation when openstack projects like Mistral needs
extra oslo.messaging functionality.
But it is too complicated now to to implement something new and
integrate it with current code because there is a little bit mess.
1) Executor should be responsible for how to run jobs
(but now also has code with server logic)
2) Dispatcher should be responsible for routing message to the
target endpoint for processing (but it also has serialisation, sending replies,
executing some executor's callbacks etc)
3) Server should do all server specific logic, we need to have different
implementation of servers for RPC and notification, not different implementations
of dispatchers
This patch fixes 1-st point
Change-Id: Ib6408f408889bb7b7056722be636a5547b1a780d
related to Id3af696193af2ccf5e5f3a1ae1d22f4f80860606. we need to make
override_pool_size accessible for external use.
Change-Id: I686c8c341f117dbc0b02443306395d5fd011c2f1
1. Use translation marker functions, their argument must just be a string
2. Any message with more than one variable should use named
interpolation instead of positional to allow translators
to move the variables around in the string to account for
differences in grammar and writing direction.
3. String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
For more details, please refert to oslo.i18n guideline [1]
Note: this commit doesn't touch test code.
[1] http://docs.openstack.org/developer/oslo.i18n/guidelines.html
Change-Id: I5f013d65b20396bbe0e5a2cceaed2a33fad1af23
This change formalises locking in MessageHandlingServer, which closes
several bugs:
* It adds locking for internal state when using the blocking executor,
which closes a number of races.
* It does not hold a lock while executing server functions,
which removes a potential cause of deadlock if the server does its
own locking.
* It fixes a regression introduced in change
gI3cfbe1bf02d451e379b1dcc23dacb0139c03be76. If multiple threads
called wait() simultaneously, only 1 of them would wait and the
others would return immediately, despite message handling not having
completed. With this change only 1 will call the underlying wait,
but all will wait on its completion.
Additionally, it introduces some new functionality:
* It allows the user to make calls in any order and it will ensure,
with locking, that these will be reordered appropriately.
* The caller can pass a `timeout` argument to any server method, which
will cause it to raise an exception if it waits too long.
* The caller can pass a `log_after` argument to any server method,
which will cause it to raise a log message if it waits too long. It
can also be used to disable logging when waiting is intentional.
We remove DummyCondition as it no longer has any users.
This change was originally committed as change
I9d516b208446963dcd80b75e2d5a2cecb1187efa, but was reverted as it
caused a hang in a Nova test. This was caused by the locking behaviour
for handling restarting a previously stopped server. The original
patch caused the state to 'wrap' immediately after the user called
wait(). This caused a hang in tests which redundantly called stop()
and wait() multiple times. This new patch only wraps when the user
calls start() again. Callers who do not restart a server will
therefore not be affected by the wrapping behaviour. Callers who do
restart a server will be no worse than before. We add a deprecation
warning on restart, as this operation is inherently racy with this api
and there is a simple, safe alternative.
This new version has been successfully tested against the unit and
functional tests of nova, cinder, glance, and ceilometer.
Change-Id: Ic79f87e7b069c1f62d6121486fd6cafd732fdde7
This reverts commit d700c38279.
This commit is causing a timeout/lock wait condition when using the in
memory rpc bus. It exposed in the Nova unit / functional tests which use
this extensively.
Change-Id: I9610a5533383955f926dbbb78ab679f45cd7bcdb
Closes-Bug: #1514876
This change formalises locking in MessageHandlingServer. It allows the
user to make calls in any order and it will ensure, with locking, that
these will be reordered appropriately. It also adds locking for
internal state when using the blocking executor, which closes a number
of races.
It fixes a regression introduced in change
gI3cfbe1bf02d451e379b1dcc23dacb0139c03be76. If multiple threads called
wait() simultaneously, only 1 of them would wait and the others would
return immediately, despite message handling not having completed.
With this change only 1 will call the underlying wait, but all will
wait on its completion.
We add a common logging mechanism when waiting too long. Specifically,
we now log a single message when waiting on any lock for longer than
30 seconds.
We remove DummyCondition as it no longer has any users.
Change-Id: I9d516b208446963dcd80b75e2d5a2cecb1187efa
This fixes a race due to the quirkiness of the blocking executor. The
blocking executor does not create a separate thread, but is instead
explicitly executed in the calling thread. Other threads will,
however, continue to interact with it.
In the non-blocking case, the executor will have done certain
initialisation in start() before starting a worker thread and
returning control to the caller. That is, the caller can be sure that
this initialisation has occurred when control is returned. However, in
the blocking case, control is never returned. We currently work round
this by setting self._running to True before executing executor.start,
and by not doing any locking whatsoever in MessageHandlingServer.
However, this current means there is a race whereby executor.stop()
can run before executor.start(). This is fragile and extremely
difficult to reason about robustly, if not currently broken.
The solution is to split the initialisation from the execution in the
blocking case. executor.start() is no longer a blocking operation for
the blocking executor. As for the non-blocking case, executor.start()
returns as soon as initialisation is complete, indicating that it is
safe to subsequently call stop(). Actual execution is done explicitly
via the new execute() method, which blocks.
In doing this, we also make FakeBlockingThread a more complete
implementation of threading.Thread. This fixes a related issue in
that, previously, calling server.wait() on a blocking executor from
another thread would not wait for the completion of the executor. This
has a knock-on effect in test_server's ServerSetupMixin. This mixin
created an endpoint with a stop method which called server.stop().
However, as this is executed by the executor, and also joins the
executor thread, which is now blocking, this results in a deadlock. I
am satisfied that, in general, this is not a sane thing to do.
However, it is useful for these tests. We fix the tests by making the
stop method non-blocking, and do the actual stop and wait calls from
the main thread.
Change-Id: I0d332f74c06c22b44179319432153e15b69f2f45
MessageHandlingServer has both MessageHandlingServer.executor, which
is the name of an executor type, and MessageHandlingServer._executor,
which is an instance of that type. Ideally we would rename
MessageHandlingServer.executor, but as this is referenced from outside
the class we change _executor instead to _executor_obj.
Change-Id: Id69ba7a0729cc66d266327dac2fd4eab50f2814c
Instead of having to spin in the wait method, just use
a condition and block until stopping has actually happened,
when stop happens, it will use the notify_all method to let
any blockers release.
Closes-Bug: #1505730
Change-Id: I3cfbe1bf02d451e379b1dcc23dacb0139c03be76
We want to ensure start have really finish before the caller
use stop to not go into weird driver state.
Inteads of raise RuntimeError or just printing warning, we
now use a lock to protect the state change of the server.
So stop will just wait that the server finish to start before
stopping.
This also removes the need to start/stop the server from the
same thread just to fix the state consistency of drivers when
thread or eventlet executor is used.
Change-Id: Ia7346f6cc0bbe8631a2e3318c7031b34ab1ec510
Add hacking rule borrowed from keystone to make sure
we don't regress and fix all the issues found by the
hacking check.
Change-Id: I41635fdd83c3e04d04f9849a72c49ccb5ac42875
Changes introduced in:
I0fc1717e3118bc1cd7b9cd0ccc072251cfb2c038
are causing Neutron to fail as summarized by Doug in:
http://markmail.org/message/2xlclp7gqnqpkted
So we should log warnings instead and make sure we
find which projects are affected (using logstash) and
fix them. Once we do that, then we can switch this
back to raise RuntimeError(s)
Change-Id: I9dce272246b89f3ec63aefcf11d385fd2d21da6e
It's documented, the application consumer must not use wait before stop.
but this is not enforced, so enforce it
Also the code assume start/stop/wait are called from the same thread,
but this is not enforced, so enforce it.
A common broken usage is:
server = oslo.messaging.get_rpc_server(..., executor='eventlet')
t = threading.Thread(target=server.start)
t.daemon = True
t.start()
...foobar code...
server.stop()
server.wait()
With monkey patching, start() will do a context switch and then stop()
is called but start is unfinished, that can cause unexpected behavior.
This patch fixes these issues by making all of this explicit.
Closes-bug: #1465850
Closes-bug: #1466001
Change-Id: I0fc1717e3118bc1cd7b9cd0ccc072251cfb2c038
Inherit MessageHandlingServer from ServiceBase.
Add the dummy "reset" method to the MessageHandlingServer.
Closes-Bug: #1470484
Change-Id: I4159450f54609c5185146472179d4299fe0c9d30
Move the public API out of oslo.messaging to oslo_messaging. Retain
the ability to import from the old namespace package for backwards
compatibility for this release cycle.
bp/drop-namespace-packages
Co-authored-by: Mehdi Abaakouk <mehdi.abaakouk@enovance.com>
Change-Id: Ia562010c152a214f1c0fed767c82022c7c2c52e7
Andreas Jaeger