Lock Stores
Rasa uses a ticket lock mechanism to ensure that incoming messages for a given conversation ID are processed in the right order, and locks conversations while messages are actively processed. This means multiple Rasa servers can be run in parallel as replicated services, and clients do not necessarily need to address the same node when sending messages for a given conversation ID.
InMemoryLockStore (default)
Description
InMemoryLockStore
is the default lock store. It maintains conversation locks within a single process.note
This lock store should not be used when multiple Rasa servers are run in parallel.
Configuration
To use the
InMemoryTrackerStore
no configuration is needed.
ConcurrentRedisLockStore
ConcurrentRedisLockStore
is a new, recommended lock store that uses Redis as a persistence layer and is safe for use with multiple Rasa server replicas.
See the migration section to learn how to switch to this lock store.
Description
The ConcurrentRedisLockStore
uses Redis as a persistence layer for instances of issued tickets and the last issued ticket number.
The ticket number initialization begins at 1, in contrast to that of theRedisLockStore
which begins at 0.
If the ticket expires, the ticket number will not be reassigned to future tickets; as a result ticket numbers are unique to ticket instances.
Ticket numbers are incremented using the Redis atomic transaction INCR on the persisted last issued ticket number.
The ConcurrentRedisLockStore
ensures that only one Rasa instance can handle a conversation at any point in time.
Therefore, this Redis implementation of the LockStore
can handle messages received in parallel for the same conversation by different Rasa servers
This is the recommended lock store for running a replicated set of Rasa servers.
Configuration
To set up Rasa with Redis the following steps are required:
- Add required configuration to your
endpoints.yml
:
- Rasa Pro <=3.7.x
- Rasa Pro >=3.8.x
To start the Rasa server using your Redis backend, add the
--endpoints
flag, e.g.:rasa run -m models --endpoints endpoints.yml
Configuration Parameters
url
(default:localhost
): The url of your redis instanceport
(default:6379
): The port which redis is running ondb
(default:1
): The number of your redis databasekey_prefix
(default:None
): The prefix to prepend to lock store keys. Must be alphanumericpassword
(default:None
): Password used for authentication (None
equals no authentication)use_ssl
(default:False
): Whether or not the communication is encrypted -socket_timeout
(default:10
): Time in seconds after which an error is raised if Redis doesn't answer
Migration Guide
To switch from the RedisLockStore
to the ConcurrentRedisLockStore
, specify the complete module path to the ConcurrentRedisLockStore
class as type
in endpoints.yml
:
- Rasa Pro <=3.7.x
- Rasa Pro >=3.8.x
You must replace the url
field in the redis lock store configuration with a field host
containing the hostname of the redis instance.
No database migration is required when switching to the ConcurrentRedisLockStore
. You can use the same Redis instance and database number as you did previously when using the RedisLockStore
.
You may want to delete all the preexisting keys if using the same Redis database number.
These former key-value items are no longer required by the ConcurrentRedisLockStore
and the database can be cleared.
There is no overlap in key-value items stored when using the RedisLockStore
and the ConcurrentRedisLockStore
, because the RedisLockStore
persists serialized TicketLock instances while the ConcurrentRedisLockStore
instead stores individual Ticket
instances, as well as the last issued ticket number.
The ConcurrentRedisLockStore
recreates the TicketLock
from the persisted Ticket
instances, which allows it to handle concurrent messages for the same conversation ID.
RedisLockStore
Description
RedisLockStore
maintains conversation locks using Redis as a persistence layer.
Configuration
To set up Rasa with Redis the following steps are required:
Add required configuration to your
endpoints.yml
lock_store:type: "redis"url: <url of the redis instance, e.g. localhost>port: <port of your redis instance, usually 6379>password: <password used for authentication>db: <number of your database within redis, e.g. 0>key_prefix: <alphanumeric value to prepend to lock store keys>To start the Rasa server using your Redis backend, add the
--endpoints
flag, e.g.:rasa run -m models --endpoints endpoints.yml
Configuration Parameters
url
(default:localhost
): The url of your redis instanceport
(default:6379
): The port which redis is running ondb
(default:1
): The number of your redis databasekey_prefix
(default:None
): The prefix to prepend to lock store keys. Must be alphanumericusername
(default:None
): Username used for authenticationpassword
(default:None
): Password used for authentication (None
equals no authentication)use_ssl
(default:False
): Whether or not the communication is encryptedssl_keyfile
(default:None
): Path to an ssl private keyssl_certfile
(default:None
): Path to an ssl certificatessl_ca_certs
(default:None
): The path to a file of concatenated CA certificates in PEM formatsocket_timeout
(default:10
): Time in seconds after which an error is raised if Redis doesn't answer
Custom Lock Store
If you need a lock store which is not available out of the box, you can implement your own.
This is done by extending the base class LockStore
.
Your custom lock store class must also implement the following methods:
get_lock
: fetches lock forconversation_id
from storage; requiresconversation_id
text parameter and returnsTicketLock
instance. (source code - see for signature).save_lock
: commitlock
object to storage; requireslock
parameter which is of typeTicketLock
and returnsNone
. (source code - see for signature).delete_lock
: deletes lock forconversation_id
from storage; requiresconversation_id
text parameter and returnsNone
. (source code - see for signature).
Configuration
Put the module path to your custom event broker and the parameters you require in your endpoints.yml
: