I am not aware of any stomp client implementation that has the concept of failover, as in tracking the commands that were issued and replaying them on a new socket connection.
All of them bubble exceptions up to the caller afaik.
But in theory, there is no impediment to having stomp failover for most use cases.
so this connection string:
Should work for a stomp client (stomp transport configured to 61613 port)? The failover protocol will determine which server is the active (Master) and connect to that one?
that won't work, the failover transport knows about JMS and openwire, not about STOMP
why not? There are STOMP clients in Perl/Python which will choose the current active broker from the list when configured with failover URL like this.
Please see Net::STOMP::Client or stomp.py for the reference.
great, good to know.
note: the caveat will be tracking subscriptions, (the sort of work that the jms openwire failover client does,) so that they can be replayed on a reconnect. This makes a reconnect transparent/seamless for the application. With STOMP, recreating context is less important because the usage pattern is typically more operation that connection orientated.
My point is that the details of failover for STOMP client implementations will vary and may be limited to connection url selection.