Django Stomp

Build Status Maintainability Test Coverage Code style: black Downloads Downloads Downloads PyPI version GitHub

A simple implementation of STOMP with Django.

In theory it can work with any broker which supports STOMP with none or minor adjustments.


pip install django_stomp

Add django_stomp in your INSTALLED_APPS and so be it.

Configuration process

Not yet fully available, but feel free to see our tests to get insights.


First you must create a function which receives an parameter of type Let's suppose the module app.sample with the following content:

import logging

from import Payload

logger = logging.getLogger(__name__)

def my_honest_logic(payload: Payload) -> None:"Yeah, I received a payload from django-stomp!")

    my_payload = payload.body
    my_header = payload.headers

    if my_payload.get("my-dict-key"):
    else:"To DLQ!")

Now you must provide broker connection details filling out the following parameters at least:


And just create the job issuing the following command:

python pubsub "/queue/your-stuff" app.sample.my_honest_logic

That's it ✌️


Here is a list of parameters that you can set in your Django project settings:


  The hostname of the STOMP server.


  The STOMP server port used to allow STOMP connections.


  The client username to connect to a STOMP server.


  The client password to connect to a STOMP server.


  Set to True, true, 1, T, t, Y or y in order to all STOMP connections use a SSL/TLS tunnel.


  The hostname of the STOMP standby server.


  The STOMP standby server port used to allow STOMP connections.


  The virtual host used in the STOMP server.


  Used to identify the subscription in the connection between client and server. See the STOMP protocol specification for more information.


  A positive integer to indicates what is the period (in milliseconds) the client will send a frame to the server that indicates its still alive. Set to 0 to means that it cannot send any heart-beat frame. See the STOMP protocol specification for more information. Defaults to 10000 ms.


  A positive integer to indicates what is the period (in milliseconds) the client will await for a server frame until it assumes that the server is still alive. Set to 0 to means that it do not want to receive heart-beats. See the STOMP protocol specification for more information. Defaults to 10000 ms.


  A positive integer to indicates how long it needs to await to try to reconnect if an Exception in the listener logic is not properly handled.


  Set to True, true, 1, T, t, Y or y in order to all STOMP topic subscription be durable. See the RabbitMQ take on it or the ActiveMQ for more information.


  A string that represents the client id for a durable subscriber or the listener prefix client id in a non-durable subscription in ActiveMQ.


  A flag that indicates if correlation-id header must be required or not. By default this flag is true (good practice thinking in future troubleshooting). Set to False, false, 0, F, f, N or n in order to allow consume messages without correlation-id header. If it's false django-stomp generates a correlation-id header for the message automatically.


  A flag to indicate if it should process a received message on background, enabling the broker-consumer communication to still take place. Set to True, true, 1, T, t, Y or y in order to have the message processing on background.


  Optional parameter that controls how many workers the pool that manage the background processing should create. If defined, this parameter must be an integer!


In order to execute tests for ActiveMQ, execute the following:

docker-compose up -d broker-activemq

Or for RabbitMQ:

docker-compose up -d broker-rabbitmq

Then at last:

pipenv run tox

Database connection management (applies to version >= 5.0.0)

For every message that a django-stomp consumer receives, it opens a new DB connection if it needs to, keeping it open until it exceeds the maximum age defined by CONN_MAX_AGE or when the connection becomes unusable.

Known limitations

  • Currently, we assume that all dead lettered messages are sent to a queue with the same name as its original destination but prefixed with DLQ., i.e., if your queue is /queue/some-queue, the dead letter destination is asssumed to be /queue/DLQ.some-queue.
  • Be cautious with the heartbeat functionality! If your consumer is slow, it could prevent the client to receive and process any heart-beat frame sent by the server, causing the client to terminate the connection due to a false positive heartbeat timeout. You can workaround it with the STOMP_PROCESS_MSG_ON_BACKGROUND parameter that uses a thread pool to process the message.
  • For the RabbitMQ users: the django-stomp consumer always try to connect to a durable queue, so if your queue is not durable, the RabbitMQ broker will not allow the subscription.
  • For versions prior to 5.0.0: Any database connection management in the consumer side is up to its callback. If you have any long-running consumer that relies on a DB connection, be sure that you manage it properly, otherwise if a connection becomes unusable, you'll have to restart the consumer entirely just to setup a new DB connection.

Download source code from Github

Download ZIP

Submit resources