Logic questions for automatic re-subscription, automatic reconnection

[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 withAutoReconnect, 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,
would it be the correct approach to disconnect the existing socket and reconnect with a new one, then re-subscribe,
if we fail to subscribe or receive an error frame through the subscription?

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

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

[joffrey-bion]

Hi! Thanks a lot for your question, and for your positive feedback too ❤️

You hit the nail right on the head. Technically, withAutoReconnect makes the connection failures invisible to the web socket client caller. Instead, the caller only sees a continuous flow of web socket frames across reconnections. In the STOMP case, the caller of the web socket client is the STOMP layer, which doesn't see web socket failures, and thus doesn't not try to re-subscribe anything.

However, the STOMP server sees the new web socket connections that follow failures. So, from its point of view, it's a new client with no subscriptions. The server will therefore no longer send messages on the old subscriptions.

Because of this, and because the Stomp client will not re-subscribe anything, the subscription flows will just hang (no new values and no errors) until the socket is actually closed. This is why some work is needed in the STOMP client itself to leverage the onReconnect callback of the reconnecting web socket client and perform the subscriptions transparently behind the scenes.

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

For now, yes. I guess the explanation above is clear enough to understand why.

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

Yes to this too.

there isn't a function in the current library to check if the socket is currently connected or not

Indeed there isn't. But if the connection fails, you will get an exception in subscription flows, and you will also see it in the instrumentation (if you register one). So I guess you could trigger the reconnection at STOMP level from the instrumentation for now.

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

It's indeed not recommended if you're using the STOMP client on top of the web socket client. It's only useful for pure web socket for now.

The topic was slightly touched here but I still haven't taken the time to clearly document this. Sorry about it.

[Kova700]

Thank you for the quick and friendly response.
Because of you, all my questions have been resolved.

I also want to express my gratitude for providing the excellent Krossbow library.
appreciate your hard work.
Have a great day! 😊👍