Auto-reconnect and auto-resubscribe at STOMP level

[joffrey-bion]

Auto-reconnect of the underlying web socket was provided with https://github.com/joffrey-bion/krossbow/issues/94, but this is not sufficient for a painless reconnect experience using STOMP.

The StompSession is stateful and has active subscription flows that would be best if kept active without hiccups after the websocket reconnection.

Note that this should also take into account heart beats and prevent MissingHeartBeatException from crashing subscriptions.

[simplatek]

thanks @joffrey-bion for your quick reply. I took your advice and added catch block before I collect now, that works but kinda do not like how all those catch blocks are invoked for session-wide errors, much harder to deal with than a session wide error handing such as at the root / immediate coroutine scope exception handler or try catch block. I also take advantage of the instrumentation error handling, which is working for me.

One thing that I don't think is working is the WebSocketConnectionException is never raised when a connection attempt fails such as trying to connect while offline for instance. I fixed it in my fork, but the KrossbowToOkHttpListenerAdapter::isConnecting parameter is never set to true, therefore the following onFailure func never resumesWithException.

override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) {
        if (isConnecting) {
            completeConnection {
                resumeWithException(WebSocketConnectionException(webSocket.request().url.toString(), cause = t))
            }
        } else {
            channelListener.onError(t)
        }
    }

Other than that, your stomp client library has been working pretty good for me so far. Nice job!

[joffrey-bion]

Hi @simplatek, thanks for your reply. For future readers, I believe you are replying to this discussion here.

that works but kinda do not like how all those catch blocks are invoked for session-wide errors

Regarding this, I'm interested in your expectations here so I can find a solution. I actually asked a question in my response. What behaviour would you expect on subscription side exactly? Would you prefer that the flow silently ends without throwing?

One thing that I don't think is working is the WebSocketConnectionException is never raised when a connection attempt fails such as trying to connect while offline for instance

Mmh good catch here. I thought I had fixed this in version 2.4.1 (issue https://github.com/joffrey-bion/krossbow/issues/138) but it turns out I made a mistake. I added a test specifically for this in all websocket implementations BUT the OkHttp one... and it happens to be the one with the bug 😅 Will reopen that issue and fix this, thanks!

EDIT: now fixed in 2.5.2

[TimOrtel]

What are your best practices to reconnect a stomp session right now for ktor (where the multiplatform solution is not yet available)? For example after a lost heart beat.

[joffrey-bion]

Even if you could wrap the STOMP client and session and react to web socket reconnections, I don't think you would have a sane way at the moment to re-subscribe the existing subscriptions to avoid the collector failures. Some ground work is needed on the STOMP implementation side to make this happen.

This takes a bit of time, sorry that I haven't progressed much on this yet.

[Kova700]

Hello, I'm a student currently developing a chat app using Krossbow. Thank you for providing such a great library.

From what I've read about reconnection issues so far, it seems that while there's an automatic reconnection feature using withAutoReconnect, we can't use the subscription flow from the previous connection. Is that correct?

If a MissingHeartBeatExceptionoccurs, should we handle socket reconnection and subscription by starting over from scratch?

If so, even with AutoReconnect, since we can't use the previous subscription flow when the socket reconnects automatically, do we need to handle subscription again?

However, as far as I know, there isn't a function in the current library to check if the socket is currently connected or not. If we can't check the socket connection status, my plan is to disconnect the existing socket and then reconnect with a new one, and then re-subscribe. Does that sound like the correct approach?

Additionally, does this mean that using the withAutoReconnectfeature is not recommended?

I'm developing my app thanks to your great library. Thank you for providing it! 👀👍

[joffrey-bion]

Hi @Kova700, sorry for the delay in the response. I answered in the discussions here: https://github.com/joffrey-bion/krossbow/discussions/515#discussioncomment-9562904