Closed repocho closed 2 years ago
stale[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
repocho
commented
2 years ago @MatthieuJnon you were involved in the https://github.com/botfront/rasa-webchat/issues/166, maybe you can help with this.
Thanks.
stale[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Proposed changes:
['websocket', 'polling']Status (please check what you already did):
Justification:: Deploying RASA in high availability and connecting with socket.io causes you to need to set up a sticky session in the load balancer (for example using the client IP). This is due to the fact that Socket.io is not using in the RASA image an adapter to use Redis and be able to load balance the socket connection among the nodes. In the documentation of socket.io, they refer that it is only happening if by default it uses "polling". With the transport "websockets" it's not needed to set up a sticky session.
By default, socket.io has the transports
["polling", "websocket"]instead of the inverse order. The inverse order (the proposed one in this pull request) is the recommended order for high availability (they mention "the order matters"). Reference: https://socket.io/docs/v3/using-multiple-nodes/The second proposed change is for configuring the timeouts (among other things). The default timeout of socket.io for reconnection is 20 seconds. But having in place a high availability RASA set up, 20 seconds is a lot and we would like to define a specific configuration for the socket connection.
This fixes #416 and probably #166. Thanks.