Adds rabbitmq-pika-driver spec
This specification contains details about new RabbitMQ pika driver implementation. Change-Id: I7bda78820e657b1e97bf888d4065a917eb317cfb
This commit is contained in:
Dmitriy Ukhlov
Davanum Srinivas
parent
b21defe366
commit
4c80ab95b1
|
|
@ -0,0 +1,267 @@
|
|||
========================================
|
||||
New RabbitMQ Pika driver implementation
|
||||
========================================
|
||||
|
||||
https://blueprints.launchpad.net/oslo.messaging/+spec/rabbit-pika
|
||||
|
||||
This specification proposes a new RabbitMQ Pika driver implementation.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Current RabbitMQ oslo.messaging driver uses Kombu client library.
|
||||
But new features support and bugfixes appear in Kombu more slower then in Pika.
|
||||
Now we have problems with RabbitMQ stable work in HA mode. And when we asked
|
||||
RabbitQM developers for help with bugfixing they said that it is possible but
|
||||
first of all, please update your environment to recommended library stack.
|
||||
It is main reason of developing this driver.
|
||||
|
||||
Also Pika supports modern RabbitMQ features, like direct reply and heartbeats.
|
||||
I guess It is preferred way to use this functionality instead developing it
|
||||
ourselves.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
In this specification I propose to create fully new driver which:
|
||||
|
||||
#. should be developed in optimal way regarding to all Pika client
|
||||
library new features and best practices;
|
||||
#. should be fully compatible with current driver interface;
|
||||
#. may change internals and does not guarantee compatibility with
|
||||
Kombu driver (means you can not use old Kombu driver for some set
|
||||
of services and new Pika driver for another services)
|
||||
#. support only current actual features without any deprecated features.
|
||||
|
||||
Features and it's design
|
||||
------------------------
|
||||
|
||||
During oslo.messaging driver investigation I seperated a few main
|
||||
supported features:
|
||||
|
||||
#. RPC - unreliable fast sending of the message to single remote server
|
||||
defined using target and getting reply.
|
||||
It has small timeout (a couple of seconds) therefore this
|
||||
message should be recieved by server and processed in real time
|
||||
(defined by timeout) or be skipped otherwise.
|
||||
#. CAST - unrelieble sending of the message to set of remote servers
|
||||
defined by target. This message should be recieved by server in real time
|
||||
(defined by timeout) or be skipped otherwise. If somehow service
|
||||
does not listen the topic or some connectivity problem occurs
|
||||
and we can not recover it fast - this server will never get the message.
|
||||
#. NOTIFY - reliable version of CAST - we can not loose the messages.
|
||||
if you send notification and send_notification method returns without any
|
||||
error - message should be stored and wait until remote server gets started
|
||||
and gets conectivity to our RabbitMQ brocker.
|
||||
|
||||
Eventlet compatibility
|
||||
----------------------
|
||||
|
||||
Pika has a few connection adapters For working with different frameworks.
|
||||
It does not have special adapter for eventlet. But It is possible to use
|
||||
'BlockingConnection' adapter and eventlet monkey patching. It works pretty
|
||||
well. Only one problem I found - it tries to use 'select.epull' API which is
|
||||
not patched by current eventlet implementation. So I added code which removes
|
||||
'pull' and 'epull' attributes from 'select' module if eventlet is patched.
|
||||
In this case Pika uses standard select api which is patched by eventlet
|
||||
correctly.
|
||||
|
||||
Heartbeats
|
||||
----------
|
||||
|
||||
Pika has it's own heartbeats mechanism. 'BlockingConnection' adapter has
|
||||
method 'process_data_events' which listen in loop response from RabbitMQ.
|
||||
It should be executed after sending request or when consumers are registered.
|
||||
This method run loop:
|
||||
|
||||
(code snippet from https://github.com/pika/pika/blob/master/pika/adapters/blocking_connection.py#L410)
|
||||
::
|
||||
|
||||
while not is_done():
|
||||
self._impl.ioloop.poll()
|
||||
self._impl.ioloop.process_timeouts()
|
||||
|
||||
which sends heartbeats (inside process_timeout_method) according to configured
|
||||
heartbeat_timeout. So we have heartbeats working for all listeners with defined
|
||||
interval. For connections used for message publishing heartbeats will be sent
|
||||
only when connection is active - when you are executing publish method.
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
#. Use old driver;
|
||||
#. Not develop fully new driver, try to just replace client library
|
||||
and keep logic of current driver
|
||||
|
||||
Impact on Existing APIs
|
||||
-----------------------
|
||||
|
||||
None.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Performance should become better because of more optimal implementation.
|
||||
|
||||
|
||||
Configuration Impact
|
||||
--------------------
|
||||
|
||||
Configuration options should be added to setup Pika client library.
|
||||
|
||||
The next configuration possibilities are suggested:
|
||||
|
||||
Connection options (represents Pika functionality):
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* 'channel_max' (default - 0) - Maximum number of channels to allow,
|
||||
* 'frame_max' (default - 131072) - The maximum byte size for an AMQP frame,
|
||||
* 'heartbeat_interval' (default - 0) - How often to send heartbeats,
|
||||
* 'ssl' (default - False) - Enable SSL or not,
|
||||
* 'ssl_options' (default - None) - SSL options if ssl is enabled,
|
||||
* 'socket_timeout' (default - 0.25) - Socket timeout for Pika connections,
|
||||
|
||||
Connection pool options:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* 'pool_max_size' (default - 10) - Maximum number of connections to keep
|
||||
queued,
|
||||
* 'pool_max_overflow' (default - 10) - Maximum number of connections to create
|
||||
above
|
||||
* 'pool_timeout' (default - 30) - Number of seconds to wait for available
|
||||
connection,
|
||||
* 'pool_recycle' (default - None) - Lifetime of a connection (since creation)
|
||||
in seconds or None for no recycling. Expired connections are closed on
|
||||
acquire,
|
||||
* 'pool_stale' (default - None) - Threshold at which inactive (since release)
|
||||
connections are considered stale in seconds or None for no staleness. Stale
|
||||
connections are closed on acquire
|
||||
|
||||
Reconnection policy options:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* 'connection_retry_attempts' (default - 3) - Reconnecting retry count in case
|
||||
of connectivity problem,
|
||||
* 'connection_retry_delay' (default - 0.1) - Reconnecting retry delay in case
|
||||
of connectivity problem,
|
||||
* 'rejected_message_retry_attempts' (default - 3) - Resend rejected messages
|
||||
retry count,
|
||||
* 'rejected_message_retry_delay' (default - 0.1) - Resend rejected messages
|
||||
retry delay
|
||||
|
||||
RPC options:
|
||||
^^^^^^^^^^^^
|
||||
|
||||
* 'rpc_queue_expiration' (default - 60) - Time to live for rpc queues without
|
||||
consumers in seconds,
|
||||
* 'default_rpc_exchange' (default - "openstack_rpc") - Exchange name for sending
|
||||
RPC messages,
|
||||
* 'rpc_reply_exchange' (default - "openstack_rpc_reply") - Exchange name for
|
||||
receiving RPC replies.
|
||||
|
||||
Notification options:
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
* 'notification_persistence' (default - False) - Persist notification messages,
|
||||
* 'default_notification_exchange' (default - "openstack_notification") -
|
||||
Exchange name for for sending notifications.
|
||||
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
Devstack should be adapted to be able to setup gate test environment with
|
||||
new driver.
|
||||
|
||||
|
||||
Testing Impact
|
||||
--------------
|
||||
|
||||
Functional tests should be adapted (without changing test logic).
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
dukhlov, yosh-m
|
||||
|
||||
Primary assignee:
|
||||
dukhlov
|
||||
|
||||
|
||||
Milestones
|
||||
----------
|
||||
|
||||
Target Milestone for completion: mitaka
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Design and implement rpc functionality (send and listen driver methods)
|
||||
based on Pika library functionality
|
||||
* Design and implement notify functionality (send_notification and
|
||||
listen_notifications driver methods)
|
||||
based on Pika library functionality
|
||||
* Adapt functional tests
|
||||
* Adapt devstack to be able to setup environment with new Pika driver
|
||||
|
||||
|
||||
Incubation
|
||||
==========
|
||||
|
||||
None.
|
||||
|
||||
|
||||
Adoption
|
||||
--------
|
||||
|
||||
Deployment guide may slightly differ because of some new config options added
|
||||
(e.g. additional ports allocated for each pipeline).
|
||||
|
||||
It worth noting that during stabilization period both drivers the old and the
|
||||
new one will stay in repos. After stabilization is over the old driver will
|
||||
be deprecated over a standard deprecation path.
|
||||
|
||||
|
||||
Library
|
||||
-------
|
||||
|
||||
oslo.messaging
|
||||
|
||||
|
||||
Anticipated API Stabilization
|
||||
-----------------------------
|
||||
|
||||
The new driver should successfully run with adapted devstack.
|
||||
Adapted oslo.messaging functional tests should successfully pass in
|
||||
devstack-gate.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Detailed doc strings should be written
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
pika library
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] https://github.com/dukhlov/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_pika.py
|
||||
.. [2] https://review.openstack.org/#/c/226348/
|
||||
|
||||
.. note::
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
Loading…
Reference in New Issue