WebSocket communication issues in multi-pod Mendix environments

Issue

Environment

Applications hosted in On-Premises

Cause

The application relies on local state or session data stored within individual pods. When the load balancer routes a WebSocket connection to a different pod than the pod that initiated the connection, the pod lacks the necessary state information, causing the application to fail to return the expected response.

In a High Availability (HA) setup with multiple pods, Mendix applications must not depend on local state such as static Java variables, local file storage, or pod-specific session data. When the load balancer distributes requests, other pods cannot access the local state stored in the specific pod.

Solution/Workaround

Implement the following best practices to ensure the application functions correctly in a multi-pod, HA environment:

• Refactor the application to ensure it does not rely on local resources such as static Java variables or local file system storage, which are unique to an individual pod.

• Ensure that System.FileDocument entities are stored in external storage (such as Amazon S3 or an equivalent service). In an HA configuration, external storage ensures data consistency regardless of which pod services the request.

• Use Task Queues instead of microflows for intensive batch processing to manage background operations and improve application stability.

• Configure session affinity at the ingress controller level to route requests from a specific user session to the same pod. Use this approach only as a last resort, as this leads to inefficient load balancing and uneven distribution of traffic across the cluster.

Additional information

• Mendix on Kubernetes
• AWS Application Load Balancer stick sessions