Data storage and publishing

In order to publish data to listeners, Tornadose utilizes a data store concept in which subscribers listen to a data store to receive updates.

class tornadose.stores.BaseStore(*args, **kwargs)

Base class for all data store types.

At a minimum, derived classes should implement submit and publish methods.

deregister(subscriber)

Stop publishing to a subscriber.

initialize(*args, **kwargs)

Hook for doing custom initialization. Child classes should implement this method instead of overwriting __init__.

publish()

Push messages to all listeners. This method must be implemented by child classes. A recommended way to implement this method is as a looping coroutine which yields until new data is available via the submit() method.

register(subscriber)

Register a new subscriber. This method should be invoked by listeners to start receiving messages.

submit(message)

Add a new message to be pushed to subscribers. This method must be implemented by child classes.

This method exists to store new data. To actually publish the data, implement the publish method.

class tornadose.stores.DataStore(*args, **kwargs)

Generic object for producing data to feed to clients.

To use this, simply instantiate and update the data property whenever new data is available. When creating a new EventSource handler, specify the DataStore instance so that the EventSource can listen for updates.

class tornadose.stores.QueueStore(*args, **kwargs)

Publish data via queues.

This class is meant to be used in cases where subscribers should not miss any data. Compared to the DataStore class, new messages to be broadcast to clients are put in a queue to be processed in order.

class tornadose.stores.RedisStore(*args, **kwargs)

Publish data via a Redis backend.

This data store works in a similar manner as DataStore. The primary advantage is that external programs can be used to publish data to be consumed by clients.

The channel keyword argument specifies which Redis channel to publish to and defaults to tornadose.

All remaining keyword arguments are passed directly to the redis.StrictRedis constructor. See redis-py‘s documentation for detais.

New messages are read in a background thread via a concurrent.futures.ThreadPoolExecutor. This requires either Python >= 3.2 or the backported futures module to be installed.

Raises:ConnectionError – when the Redis host is not pingable