WebSocket connection closes with code 1006 (Abnormal Closure) after 45 seconds when simulating 500 concurrent agents via JMeter. The initial handshake returns HTTP 200 OK, and the connection remains stable for the first minute. However, as soon as the script starts sending keep-alive pings at 30-second intervals, the Edge node drops the connection immediately. This happens consistently on Genesys Cloud Edge version 2023-11-15. No errors appear in the Genesys Cloud audit logs, but the JMeter response message shows “java.net.SocketException: Connection reset”.
The load test uses a custom JSR223 PreProcessor to generate unique Agent IDs and a WebSocket Sampler plugin. The target endpoint is wss://edge-<id>.genesyscloud.com/agent-desktop. We have verified that the TLS certificates are valid and the Edge health checks return green. The issue seems related to how the Edge handles idle connections or ping frames under load. Has anyone seen this specific 1006 error pattern during high-concurrency agent simulation? Looking for advice on JMeter WebSocket sampler configuration or Edge timeout settings that might mitigate this.
jmeter_config:
websocket:
ping_interval_ms: 15000 # Reduce from 30000
ping_timeout_ms: 5000
idle_timeout_ms: 60000
The 1006 closure usually stems from a mismatch between the JMeter ping interval and the Edge node's idle timeout enforcement. The Edge proxy expects activity within a specific window. If the 30-second ping arrives too late or the payload is malformed, the server side drops the socket.
* **Adjust Ping Interval**: Set the WebSocket sampler ping interval to 15 seconds. The default 30-second interval often overlaps with the Edge's internal keep-alive check, causing a race condition.
* **Verify Payload Format**: Ensure the ping frame contains a valid UTF-8 payload. Empty pings are sometimes rejected by stricter Edge configurations. Use a simple string like "ping" or a JSON object `{"type":"ping"}`.
* **Check Rate Limits**: 500 concurrent agents generating pings simultaneously can trigger rate limiting on the WebSocket endpoint. Stagger the ping start times in JMeter using a Gaussian Random Timer or add a small random delay (e.g., 500ms) to each thread group.
* **Review Edge Logs**: While Genesys Cloud audit logs may be silent, check the Edge node logs directly if BYOC. Look for `ws:close` events with reason codes. A 1006 often masks an underlying 1008 (Policy Violation) or 1009 (Message Too Big) error.
* **Update JMeter Plugin**: Ensure the WebSocket Sampler plugin is up to date. Older versions have bugs handling fragmented frames or specific TLS extensions used by Genesys Edge.
This configuration stabilizes the connection by aligning the client heartbeat with the server's expectations. Monitor the error rate after applying these changes. If issues persist, reduce the concurrency to 100 agents and scale up gradually to isolate the threshold.