Sometimes, the client does not send a ping, resulting in a 'Session Closed' problem.

[29pass30]

Sometimes the client don't send ping, the session is closed by server. The client: const client = new StompJs.Client({ brokerURL: 'ws://localhost:8080/websocket/push', connectHeaders: { login: ' ', passcode: ' ', }, debug: function (str) { console.log(str); }, reconnectDelay: 5000, heartbeatIncoming: 5000, heartbeatOutgoing: 5000, });

[29pass30]

I solved this problem. solution:

 heartbeatIncoming: 120000, heartbeatOutgoing: 120000

Timer delayed execution due to certain reasons, so increase the interval for heartbeat.

Analyze the cause. this._pinger = setInterval(() => { if (this._webSocket.readyState === exports.StompSocketState.OPEN) { this._webSocket.send(BYTE.LF); this.debug('>>> PING'); } }, ttl);

stomp.js use setInterval to send a ping every 'ttl' seconds. Obviously the timer did not send a ping due to certain reasons. After a certain period of time, the server disconnected the session.

[StareStarrySky]

Have you known the reason? Considering as a bug?

[jnovak-netsystemcz]

I'm touching same issue...

I analysed whole chain: We use stomp-js based client, than tomcat/STOMP as backend and ActiveMQ as broker. We are passing messages thru WS between the client and ActiveMQ.

The issue is that even both sides (client/stomp-js and ActiveMQ) agree on same heartbeat timer and follow it, after some time it may happen that heartbeat message is delayed in transport for one or two ms. Therefore one or another side receives it too late and drop the connection because timer expired. ActiveMQ is dropping the connection more often in my case.

I tried to send a message a little earlier and accept a smaller higher delay than negotiated. I tested to multiply ttl 0.9 for sending and ttl 1.1 for reception.

So I propose to create property which will control the difference - scale or absolute value. Or use same approach like for PONG - there is fixed coefficient 2. So it can use ttl / 2 for PING.