Session Management with Multiple RASA Instances

Hi, We have RASA deployed on multiple instances and based on the documentation, a unique session id has to be created at the start of the conversation and pass the session id to rasa, until the conversation with the end user is done.

To my understanding the session is persisted IN Memory with in the RASA Instance. What will happen if the load balancer sends the same user request to a different RASA Instance instead of sending it to the instance where the session is created and persisted. We are using the “/trigger_intent” end point as we are doing NLP /Intent prediction outside RASA. We are cacheing the slots and sending them as part of every request.

Does RASA Core use the the tracker events history to predict the next action? . If RASA core uses tracker events to predict the next action , we have to sync the session across all the instances, so we wanted to know how it works behind the scene. As of now we are not sending the tracker events history, when the call goes to a different instance where does not have session.

Kubernetes and the helm chart is recommended in this case.

You don’t want to use the in memory tracker store as you’ve suggested. There are several options for tracker stores described here. Along with this, you’ll want to use the Redis Lock Store to managing locking across the instances.

Thanks

@stephens Can you also help us understand, if RASA core uses the tracker events to determine the next action when we use the “/trigger_event” endpoint? As part of “/trigger_intent” invocation, we cache and send slots with every invocation untill the conversation is ended.

if RASA core uses the tracker events to determine the next action

Yes

when we use the “/trigger_event” endpoint

I’m not familiar with an endpoint by this name. The slash syntax is associated with invoking an intent so I assume you’re talking about invoking an intent that triggers an action.

yes, here is the end point i am referring to Rasa Open Source Documentation.