Version: Latest

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:

  1. Add required configuration to your endpoints.yml:
lock_store:
type: concurrent_redis
host: "host 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"
  1. 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 instance
  • port (default: 6379): The port which redis is running on
  • db (default: 1): The number of your redis database
  • key_prefix (default: None): The prefix to prepend to lock store keys. Must be alphanumeric
  • password (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:

lock_store:
type: concurrent_redis
host: "host 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"

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:

  1. 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>
  2. 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 instance

  • port (default: 6379): The port which redis is running on

  • db (default: 1): The number of your redis database

  • key_prefix (default: None): The prefix to prepend to lock store keys. Must be alphanumeric

  • username (default: None): Username used for authentication

  • password (default: None): Password used for authentication (None equals no authentication)

  • use_ssl (default: False): Whether or not the communication is encrypted

  • ssl_keyfile (default: None): Path to an ssl private key

  • ssl_certfile (default: None): Path to an ssl certificate

  • ssl_ca_certs (default: None): The path to a file of concatenated CA certificates in PEM format

  • socket_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:

Configuration

Put the module path to your custom event broker and the parameters you require in your endpoints.yml:

endpoints.yml
lock_store:
type: path.to.your.module.Class
url: localhost
a_parameter: a value
another_parameter: another value