-
1. Re: Master/Slave configuration and failover support for the stomp protocol
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.
-
2. Re: Master/Slave configuration and failover support for the stomp protocol
so this connection string:
failover://(tcp://server1:61613,tcp://server2:61613)?randomize=false
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?
-
3. Re: Master/Slave configuration and failover support for the stomp protocol
that won't work, the failover transport knows about JMS and openwire, not about STOMP
-
4. Re: Master/Slave configuration and failover support for the stomp protocol
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.
failover://(tcp://server1:61613,tcp://server2:61613)?randomize=false
Please see Net::STOMP::Client or stomp.py for the reference.
-
5. Re: Master/Slave configuration and failover support for the stomp protocol
@buchi
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.