You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen flowise is based on socket.io in order to communicate with the client.
I wonder what would happen if flowise will have multiple nodes/replicas/pods, how can we keep that the sessions of socket.io won't be sticky to a specific node/replica/pod?
a new socket connection is established/closed whenever user open or close the chatbox, so in the case of multiple nodes/replicas/pods I dont think that will be an issue. Though we are working on using SSE and moving away from socketio
a new socket connection is established/closed whenever user open or close the chatbox, so in the case of multiple nodes/replicas/pods I dont think that will be an issue. Though we are working on using SSE and moving away from socketio
I'm not sure that's true.
Think of a case where you're using kubernetes and you have a public ingress, your service holds let's say 3 pods for the example.
Now once you open the chatbot you were interacting with pod #1 , later on the ingress decided to route your request to pod #3. In that case the application will fail.
In such cases you must use persistency in order to avoid session stickiness.
Hi,
I've seen flowise is based on socket.io in order to communicate with the client.
I wonder what would happen if flowise will have multiple nodes/replicas/pods, how can we keep that the sessions of socket.io won't be sticky to a specific node/replica/pod?
I didn't see flowise has the option to integrate socket.io with a certain adapter (https://socket.io/docs/v4/using-multiple-nodes/#enabling-sticky-session) nor configure the transports as
websocket
Thanks,
The text was updated successfully, but these errors were encountered: