stomp-js
Unable to reconnect when there is an error during deactivation
We are getting the issue that when a session expired and the call to deactivate() timed out, it is not possible to call activate() again after the user has logged-in because the client is still in the state DEACTIVATING.
As an explanation, our application is a hybrid mobile application and therefore there is no reload after login.
Currently there is just an exception "Still DEACTIVATING, can not activate now" being thrown when calling activate while the activation state is DEACTIVATING.
Would there be a way to double check if the socket was really being closed? And in that case just wait and then reconnect?
Or add a timeout to deactivate that changes the state to INACTIVE after a few seconds.
We're seeing an similar error. We only see this on iOS on WKWebView, we do not see it in either Safari on iOS or Android. We've managed to reproduce it by doing the following:
- Start the app and open a connection
- Put the app in background for approximately 15 minutes
- Open the app again
Not that unexpected; the OS has closed the WebSocket-connection in order to save user battery. However, when the automatic reconnect tries to reconnect we can see Already ACTIVE, ignoring request to activate. After that, we get the following message every 25 seconds (which is our heartbeat setting for both incoming and outgoing):
did not receive server activity for the last 852462ms
Issuing close on websocket
It should be noted that we are using the library rx-stomp; but I believe the problem comes down here somewhere. Do you believe this is the same error or should I open a seperate ticket for this?
@andreandersson It is very likely that this is the same error. We are also using a Webview on iOS and the error happened there.
We've gotten some improvements by enabling discardWebsocketOnCommFailure, as a temporary (or permanent?) workaround. Sadly our entire app is pretty "seasonal", so we won't know for sure how much it has helped until next year.
@andreandersson This makes sense. The source of truth for the connection is the connection itself, not the variable in Stomp.js.
The next version (to be released as a beta first) refactors client.deactivate and introduces the concept of force.
Calling client.deactivate more than once is now supported with predictable behavior - this call is async, and all calls will resolve when the underlying connection terminates.
The newly introduced option force in client.deactivate internally use a mechanism similar to discardWebsocketOnCommFailure to discard the undelring WebSocket.
It is valid to call client.deactivate and then subsequently call client.deactivate with the option force. This paves the way to implement (at this point outside the library) a mechanism to implement a deactivate timeout, after which it discards the WebSocket and moves on.
