Skip to main content
Pre-release

This release is a pre-release and may not be stable for production use.

Pika

RabbitMQ (AMQP 0-9-1) client library for Python

Version Python versions Downloads Actions Status Coverage License Docs

Introduction · Documentation · Example · Examples · Adapters · Contributing

Introduction

Pika is a pure-Python implementation of the AMQP 0-9-1 protocol including RabbitMQ's extensions.

  • Supports Python 3.7+ (CPython and PyPy; versions are listed on PyPI). Pika 1.1.0 was the last release that supported Python 2.7.
  • Since threads aren't appropriate to every situation, it doesn't require threads. Pika core takes care not to forbid them, either. The same goes for greenlets, callbacks, continuations, and generators. Most connection adapters are single-threaded; use Connection when you need to publish or consume from multiple threads.
  • People may be using direct sockets, plain old select(), or any of the wide variety of ways of getting network events to and from a Python application. Pika tries to stay compatible with all of these, and to make adapting it to a new environment as simple as possible.

Documentation

Pika's documentation can be found here.

Example

Sending a message with pika.Connection, which is thread-safe and runs its own IOLoop on a background thread:

import pika

connection = pika.Connection(pika.ConnectionParameters())
channel = connection.channel()

# RabbitMQ 4.3 and later refuse a queue that is neither durable nor exclusive.
channel.queue_declare('test', durable=True)
channel.basic_publish(exchange='', routing_key='test', body=b'Test message.')
connection.close()

And consuming, where each delivery is dispatched on a per-channel worker thread, so slow processing does not stall heartbeats and basic_ack needs no add_callback_threadsafe:

import threading

import pika

connection = pika.Connection(pika.ConnectionParameters())
channel = connection.channel()
channel.queue_declare('test', durable=True)

def on_message(ch, method_frame, properties, body):
    print(method_frame, properties, body)
    ch.basic_ack(method_frame.delivery_tag)

channel.basic_consume('test', on_message)

try:
    # The IOLoop already runs in the background; block until interrupted.
    threading.Event().wait()
except KeyboardInterrupt:
    connection.close()

Adapters

Pika provides the following adapters:

  • pika.Connection - thread-safe, runs SelectConnection's IOLoop in a background thread. All channel methods are safe to call from any thread simultaneously.
  • pika.SelectConnection - asynchronous adapter without third-party dependencies.
  • pika.adapters.asyncio_connection.AsyncioConnection - asynchronous adapter for AsyncIO's I/O loop.
  • pika.BlockingConnection - synchronous and procedural (deprecated, removed in Pika 2.0).
  • pika.adapters.gevent_connection.GeventConnection - asynchronous adapter for use with Gevent's I/O loop (deprecated, removed in Pika 2.0).
  • pika.adapters.tornado_connection.TornadoConnection - asynchronous adapter for use with Tornado's I/O loop (deprecated, removed in Pika 2.0).
  • pika.adapters.twisted_connection.TwistedProtocolConnection - asynchronous adapter for use with Twisted's I/O loop (deprecated, removed in Pika 2.0).

Multiple connection parameters

You can also pass multiple pika.ConnectionParameters instances for fault-tolerance as in the code snippet below (host names are just examples, of course). To enable retries, set connection_attempts and retry_delay as needed in the last pika.ConnectionParameters element of the sequence. Retries occur after connection attempts using all of the given connection parameters fail.

import pika

parameters = (
    pika.ConnectionParameters(host='rabbitmq.zone1.yourdomain.com'),
    pika.ConnectionParameters(host='rabbitmq.zone2.yourdomain.com',
                              connection_attempts=5, retry_delay=1))
connection = pika.BlockingConnection(parameters)

With non-blocking adapters, such as pika.SelectConnection and pika.adapters.asyncio_connection.AsyncioConnection, you can request a connection using multiple connection parameter instances via the connection adapter's create_connection() class method.

Threading

pika.Connection is the simplest way to use Pika from multiple threads. It runs the IOLoop in a background thread and provides a blocking API that is safe to call from any number of threads simultaneously. Consumer callbacks run on a per-channel worker thread, so slow processing does not stall heartbeats as long as the callback keeps pace with deliveries:

import pika

conn = pika.Connection(pika.ConnectionParameters('localhost'))
ch = conn.channel()

# RabbitMQ 4.3 and later refuse a queue that is neither durable nor exclusive.
ch.queue_declare('work', durable=True)

def on_message(channel, method, properties, body):
    process(body)
    channel.basic_ack(method.delivery_tag)  # safe, no callback scheduling needed

ch.basic_consume('work', on_message)

See examples/basic_consumer_threaded.py and examples/basic_publisher_threaded.py.

Using add_callback_threadsafe (manual approach)

For other adapters, each connection instance is confined to a single thread. The single-threaded constraint may result in a dropped connection due to AMQP heartbeat timeout in consumers that take a long time to process a message. A common solution is to delegate processing to another thread while the connection's IOLoop thread services heartbeats.

Messages processed in another thread may not be acknowledged directly from that thread. Instead, schedule a callback in the adapter's IOLoop thread:

def ack_message(channel, delivery_tag):
    """Note that `channel` must be the same Pika channel instance via which
    the message being acknowledged was retrieved (AMQP protocol constraint).
    """
    if channel.is_open:
        channel.basic_ack(delivery_tag)
    else:
        # Channel is already closed, so we can't acknowledge this message;
        # log and/or do something that makes sense for your app in this case.
        pass

The code running in the other thread may request the ack_message() function to be executed in the connection adapter's I/O loop thread using an adapter-specific mechanism:

  • pika.BlockingConnection abstracts its I/O loop from the application and thus exposes pika.BlockingConnection.add_callback_threadsafe(). Refer to this method's docstring for additional information. For example:
connection.add_callback_threadsafe(functools.partial(ack_message, channel, delivery_tag))
  • When using a non-blocking connection adapter, such as pika.adapters.asyncio_connection.AsyncioConnection or pika.SelectConnection, you use the underlying asynchronous framework's native API for requesting an I/O loop-bound callback from another thread. For example, pika.SelectConnection's I/O loop provides add_callback_threadsafe(), pika.adapters.tornado_connection.TornadoConnection's I/O loop has add_callback(), while pika.adapters.asyncio_connection.AsyncioConnection's I/O loop exposes call_soon_threadsafe().

This threadsafe callback request mechanism may also be used to delegate publishing of messages, etc., from a background thread to the connection adapter's thread.

Connection recovery

Some RabbitMQ clients (Bunny, Java, .NET, Objective-C, Swift) provide a way to automatically recover a connection, its channels and topology (e.g. queues, bindings and consumers) after a network failure. Others require connection recovery to be performed by the application code and strive to make it a straightforward process. Pika falls into the second category.

Pika supports multiple connection adapters. They take different approaches to connection recovery.

For pika.BlockingConnection adapter exception handling can be used to check for connection errors. Here is a very basic example:

import pika

while True:
    try:
        connection = pika.BlockingConnection()
        channel = connection.channel()
        channel.basic_consume('test', on_message_callback)
        channel.start_consuming()
    # Don't recover if connection was closed by broker
    except pika.exceptions.ConnectionClosedByBroker:
        break
    # Don't recover on channel errors
    except pika.exceptions.AMQPChannelError:
        break
    # Recover on all other connection errors
    except pika.exceptions.AMQPConnectionError:
        continue

A variant that recovers across several nodes is in examples/blocking_consume_recover_multiple_hosts.py.

Generic operation retry libraries such as retry can be used. Decorators make it possible to configure some additional recovery behaviours, like delays between retries and limiting the number of retries:

import pika
from retry import retry


@retry(pika.exceptions.AMQPConnectionError, delay=5, jitter=(1, 3))
def consume():
    connection = pika.BlockingConnection()
    channel = connection.channel()
    channel.basic_consume('test', on_message_callback)

    try:
        channel.start_consuming()
    # Don't recover connections closed by server
    except pika.exceptions.ConnectionClosedByBroker:
        pass


consume()

The same decorator applied across several nodes is in examples/blocking_consume_recover_multiple_hosts_retry.py.

For asynchronous adapters, use on_close_callback to react to connection failure events. This callback can be used to clean up and recover the connection.

An example of recovery using on_close_callback can be found in examples/asynchronous_consumer_example.py.

Contributing

See the Contributing guide for test setup, documentation builds, code formatting, and pull request expectations.

Extending to support additional I/O frameworks

New non-blocking adapters may be implemented in either of the following ways:

  • By subclassing pika.BaseConnection, implementing its abstract method and passing its constructor an implementation of pika.adapters.utils.nbio_interface.AbstractIOServices. pika.BaseConnection implements pika.connection.Connection's abstract methods, including internally-initiated connection logic. For examples, refer to the implementations of pika.adapters.asyncio_connection.AsyncioConnection, pika.adapters.gevent_connection.GeventConnection and pika.adapters.tornado_connection.TornadoConnection.
  • By subclassing pika.connection.Connection and implementing its abstract methods. This approach facilitates implementation of custom connection-establishment and transport mechanisms. For an example, refer to the implementation of pika.adapters.twisted_connection.TwistedProtocolConnection.

Release files for pika 1.5.0rc1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for pika 1.5.0rc1
File Size Uploaded Provenance
pika-1.5.0rc1.tar.gz 197.2 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for pika 1.5.0rc1
File Interpreter ABI Platform
pika-1.5.0rc1-py3-none-any.whl Python 3 none any Details

Total release size: 404.6 kB

Release files / pika-1.5.0rc1.tar.gz

Download URL pika-1.5.0rc1.tar.gz
Size 197.2 kB
Tags Source
SHA-256 checksum
How to use checksums
5141f4c94f24232244c6dff03a327eca2e92282b4a85d94a65c11aa5bc1d7bb2
BLAKE2b-256 checksum
How to use checksums
14a7c709e4d1dc295304dce031a72eb3ef2e6a1e8632ef608965cc9116ab7d55
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.13.14

Release files / pika-1.5.0rc1-py3-none-any.whl

Download URL pika-1.5.0rc1-py3-none-any.whl
Size 207.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
d4dd95e89632540d44352142053fedbdfb886a2f6de33b6a6547a005e842438b
BLAKE2b-256 checksum
How to use checksums
c6c8b41cfa7eb691b2a194cc9cd1673fa98d6f4691ca0b761876d2e082bab041
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.13.14

Security for pika 1.5.0rc1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release
Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page