3067dbd198
The main issue with eventlet.green.zmq is that libzmq as a C-library is completely monkey-patch unfriendly. So any blocking call inside the native library makes calling process stuck. We can't avoid this actually in an absolutely normal situation when a client appears earlier than listener we have all client process get stuck until listener raised. If the listener for example is also blocked awaiting for some other service to appear we have a chain of locks which may occasionally result in a dead-lock. The other situation with Notifier is quite similar. For that reason zmq-broker was restored, but now it serves as an outgoing queue on a client side. Servers remained the same dynamically port-binded. Now all clients can still use green-zmq, but presence of the broker-queue on a host guarantees that green threads will never blocked in a client because all messages will wait their listeners inside the broker queue. The broker process's modules are not monkey-patched, they make use of native threading and native zmq. Possibility to run without broker also remains. The option zmq_use_broker introduced for that reason. Closes-Bug: #1497315 Change-Id: I786b100fd6ee1cf4b99139db0ca044d358d36345 |
||
|---|---|---|
| doc/source | ||
| etc | ||
| oslo.messaging/locale | ||
| oslo_messaging | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| babel.cfg | ||
| requirements.txt | ||
| setup-test-env-qpid.sh | ||
| setup-test-env-rabbit.sh | ||
| setup-test-env-zmq.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Oslo Messaging Library
The Oslo messaging API supports RPC and notifications over a number of different messaging transports.
- License: Apache License, Version 2.0
- Documentation: http://docs.openstack.org/developer/oslo.messaging
- Source: http://git.openstack.org/cgit/openstack/oslo.messaging
- Bugs: http://bugs.launchpad.net/oslo.messaging