Data Action WebSocket Disconnects During JMeter Ramp-Up

Just noticed that the WebSocket connection for the Data Action API drops with a 1006 error code when the JMeter thread group hits 50 concurrent users. The environment is Genesys Cloud v2.98.0 in the US-East region. The test plan uses a simple JSON payload to trigger a custom data action named ‘LookupCustomerInfo’ via the /api/v2/analytics/events/realtime endpoint. The initial ramp-up phase with 10 threads works perfectly, returning 200 OK responses and valid JSON data. However, as soon as the concurrency increases to 50 threads per minute, the client-side logs show immediate connection closures without any retry logic from the SDK. The JMeter configuration sets the Content-Type to application/json and includes the necessary Bearer token for authentication. The timeout settings are set to 30000 milliseconds, which should be sufficient for a simple database lookup. The issue persists even when the data action logic is simplified to just a static JSON return, suggesting the problem lies in the connection handling rather than the backend processing time.

The goal is to validate the maximum throughput of the Data Action service before the peak season. The current setup uses the Genesys Cloud Java SDK version 14.5.0 for the WebSocket implementation. The error logs do not provide a specific reason for the 1006 close code, only that the server closed the connection unexpectedly. The network latency between the JMeter server and the Genesys Cloud endpoint is consistently under 50 milliseconds. The question is whether there is a specific concurrent connection limit for Data Actions that is lower than the standard API rate limits. The documentation mentions general WebSocket limits, but it does not specify if Data Actions share this pool with other real-time services like Agent Desktop or IVR. Any guidance on configuring the JMeter HTTP Request sampler to handle these disconnects gracefully or on identifying the exact bottleneck would be appreciated. The test environment is isolated, so no other traffic is interfering with the connections.

Have you tried isolating the Data Action configuration from the high-volume traffic simulation to determine if the issue stems from the Genesys Cloud platform limits or the external system’s capacity? The 1006 error code indicates an abnormal closure, which often occurs when the backend service handling the Data Action request fails to respond within the expected timeout window, causing the WebSocket to drop unexpectedly.

In enterprise environments, it is crucial to verify that the Data Action is configured with appropriate retry policies and timeout values. If the external system cannot handle the ramp-up, the platform may terminate the connection to preserve resources. Consider adjusting the Data Action settings to include a higher timeout value and enable retry logic for transient failures.

WebSocket connection failed: Error code 1006 - Abnormal Closure

Additionally, review the Genesys Cloud Performance dashboard for any spikes in queue activity or agent performance metrics that might correlate with the Data Action failures. While the Data Action itself is not directly tied to agent performance, high system load can impact overall responsiveness. Ensure that the JSON payload being sent in the JMeter test is optimized and does not contain unnecessary data that could increase processing time.

If the issue persists, consider implementing a circuit breaker pattern in your external system to handle high volumes gracefully. This can prevent the system from being overwhelmed and reduce the likelihood of WebSocket disconnections. Finally, consult the Genesys Cloud documentation for best practices on Data Action configuration and performance tuning to ensure optimal setup.

TL;DR:
You need to increase the WebSocket keep-alive interval in your JMeter config, as the default timeout often kills idle connections before the external lookup finishes. Try setting it to 30000ms to match the Genesys Cloud default.