Quick question about the stability of the Genesys Cloud Digital Messaging WebSocket connections under sustained load. We are currently running a JMeter 5.6.2 script from our Singapore office (Asia/Singapore) to simulate a spike in customer engagement. The goal is to validate the platform’s capacity for a major retail client’s Black Friday prep.
The setup involves creating 500 concurrent messaging sessions using the /api/v2/analytics/conversations/details/realtime endpoint to monitor state, while simultaneously pushing messages via the standard digital channel API. For the first 15 minutes, the throughput looks healthy. We see roughly 200 messages per second being processed without issue. However, exactly at the 16-minute mark, the WebSocket connections begin to terminate unexpectedly.
We are not seeing a standard 429 Too Many Requests error in the response headers, which is confusing because our previous tests on Architect flows hit that wall immediately. Instead, the client-side logs show a generic connection closed event with no specific error code from the server. The JMeter listeners report a sudden drop in active threads from 500 to about 120 within 30 seconds.
We have verified that the API keys have sufficient permissions and that the rate limit headers in the initial handshake look normal. The environment is the standard US-East production instance. We are using the latest Java SDK for the initial token exchange but handling the WebSocket manually via HTTP Client 4.5.13 in the JMeter script to minimize overhead.
Is there a known hard limit on the number of concurrent active digital messaging sessions per organization or per API key? Or could this be a timeout issue related to the heartbeat mechanism in our JMeter script? We tried increasing the heartbeat interval to 30 seconds, but the drop still happens. Any insights into how Genesys handles connection pooling for digital channels at this scale would be helpful. Does anyone know the specific concurrent session limit for Digital Messaging WebSockets or how to properly configure the heartbeat to prevent premature disconnects at 500 threads?