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.
Base class for all data store types.
At a minimum, derived classes should implement
Stop publishing to a subscriber.
Hook for doing custom initialization. Child classes should implement this method instead of overwriting
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
Register a new subscriber. This method should be invoked by listeners to start receiving messages.
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
Generic object for producing data to feed to clients.
To use this, simply instantiate and update the
dataproperty whenever new data is available. When creating a new
EventSourcehandler, specify the
DataStoreinstance so that the
EventSourcecan listen for updates.
Publish data via queues.
This class is meant to be used in cases where subscribers should not miss any data. Compared to the
DataStoreclass, new messages to be broadcast to clients are put in a queue to be processed in order.
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.
channelkeyword argument specifies which Redis channel to publish to and defaults to
All remaining keyword arguments are passed directly to the
redis.StrictRedisconstructor. 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
futuresmodule to be installed.
Raises: ConnectionError – when the Redis host is not pingable