The document discusses the design and features of a new Pika RabbitMQ driver being developed to replace an existing Kombu driver. Key changes in the Pika driver include using different exchange types for different message types, optional persistence only for notifications, queues and exchanges with expiration periods, and a new approach for clients to declare queues for notifications. The driver aims to improve performance by using direct exchanges where possible and utilizes features of the Pika library like its own reconnection mechanism and heartbeat.

1. Copyright © 2015 Mirantis, Inc. All rights reserved
www.mirantis.com
Pika RabbitMQ driver
Design and features overview
Dmitriy Ukhlov
Software Engineer
dukhlov@mirantis.com
IRC, launchpad: dukhlov

2. Copyright © 2015 Mirantis, Inc. All rights reserved
Pika driver requirements
● should be developed from scratch
● 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 other services)
● should support only current actual features without any deprecated features.

3. Copyright © 2015 Mirantis, Inc. All rights reserved
Oslo.messaging driver use cases
1. CALL – client sends message to one of the set of servers defined by target
which currently listen topic and waits for response during short timeout;
2. CAST – client sends message to each or only one of the set of servers
defined by target which currently listen topic;
3. NOTIFY – client sends message to each of the set of servers which have
permanent subscription for topic and will receive message even if they
don't listen topic currently

4. Copyright © 2015 Mirantis, Inc. All rights reserved
CALL solution
Exchange
name =
rpc_exchange
type = direct
auto_delete =
True
durable = False
routing_key =
<topic> or
<topic>.<server>
reply_q =
<project>.<prog_name>.<process_id>
expiration = <timeout>
mandatory = True
delivery_confirmation = enabled
persistence = False
Queue
name =<topic>
auto_delete = False
durable = False
X-expires = 60 s
Queue
name = <topic>.<server>
auto_delete = False
durable = False
X-expires = 60 s
<server>
Exchange
name =
rpc_reply_exchang
e
type = direct
auto_delete = True
durable = False
Queue
name =<project>.<prog_name>.<process_id>
auto_delete = False
durable = False
X-expires = 60 s
routing_key =
<project>.<prog_name>.<process_id>
expiration = <timeout>
mandatory = False
delivery_confirmation = enabled
persistence = False

5. Copyright © 2015 Mirantis, Inc. All rights reserved
CALL solution features
● Expired RabbitMQ resources (queues, exchanges and messages) cleanup;
● Using direct exchanges to make routing faster;
● Using single reply listener per client process to make call faster;
● Using delivery confirmation to get maximum information about connectivity problems;
● Connectivity fault tolerant (call will survive short time connectivity problem)
● Using message listening without confirmation (prevents redelivery and processing one message
a few times)

6. Copyright © 2015 Mirantis, Inc. All rights reserved
CAST solution
Exchange
name =
openstack_rpc
type = direct
auto_delete = True
durable = False
routing_key =
<topic> or
<topic>.<server>
expiration = <timeout>
mandatory = True
delivery_confirmation = enabled
persistence = False
Queue
name =<topic>
auto_delete = False
durable = False
X-expires = 60 s
Queue
name = <topic>.<server>
auto_delete = False
durable = False
X-expires = 60 s
<server>
Exchange
name =
openstack_rpc_fanout_<topic>
type = fanout
auto_delete = True
durable = False
expiration = <timeout>
mandatory = True
delivery_confirmation =
enabled
persistence = False

7. Copyright © 2015 Mirantis, Inc. All rights reserved
CAST solution features
● Expired RabbitMQ resources (queues, exchanges and messages) cleanup;
● Using direct and fanout exchanges (instead topic) to make routing faster;
● Using delivery confirmation to get maximum information about connectivity problems;
● Connectivity fault tolerant (detecting problem which could be recovered and retry)
● Using message listening without confirmation (prevents re-delivery and processing one message
a few times)

8. Copyright © 2015 Mirantis, Inc. All rights reserved
Notify solution
Exchange
name =
openstack_notification
type = direct
auto_delete = False
durable = True
routing_key =
<topic>.<priority>
expiration = <timeout>
mandatory = True
delivery_confirmation = enabled
persistent = <notification_persistence>
Queue
name =<topic>.<priority>
auto_delete = False
durable = True
<primary server><secondary server>
Queue
name =<custom_server_name>
auto_delete = False
durable = True

9. Copyright © 2015 Mirantis, Inc. All rights reserved
Notify solution features
● Durable exchanges and queues are used to survive RabbitMQ restart
● Client will create default queue <topic>.<priority> if it can not deliver message to any other
queue;
● By default delivery is guaranteed if you use only one listener and it listen default queues. In any
other case you prepare RabbitMQ durable queues, exchanges and its bindings before starting
Notification clients (for example by running all servers before client)
● Using direct exchange (instead of topic) to make routing faster;
● Using delivery confirmation to get maximum information about connectivity problems;
● Connectivity fault tolerant (detecting problem which could be recovered and retry)
● Using message listening with confirmation (prevents message losing in case of notification
listener crash)

10. Copyright © 2015 Mirantis, Inc. All rights reserved
Key changes in pika driver comparing to kombu
● using direct exchanges instead of topic exchanges
● using separate exchanges for different message types
● using optional persistence only for notifications (durable exchange and queues and persistent messages)
● rpc queues and exchanges with expiration period - will we deleted by RabbitMQ if any service does not
connected.
● new approach of creating queues for notifications by client (client tries to send notification with mandatory flag
and declare default queue it message get returned, which means that there is now queue for routing message
now)
● using single reply listener per application (not per request)
● using own reconnection mechanism implemented in pika driver and able to work correctly in ha mode
● HA configuration is removed. It could be configured via RabbitMQ policies
● using heartbeat mechanism implemented in pika library