Bug #74738 for Net-STOMP-Client: Failover is not working in the middle of publish or subscribe

Tue Feb 07 03:05:32 2012 http://buchireddy.blogspot.com/ - Ticket created

Subject:

Failover is not working in the middle of publish or subscribe

Hi, [This is the first time I'm logging a bug in CPAN code so please correct me if I'm not following any conventions here] I'm trying to use Net::STOMP::Client to communicate with my ActiveMQ broker and I would like my client to have failover support. So, I've instantiated the client with proper uri which has to hosts specified and I've seen that the client fails over to the second broker if the first one is not reachable. However, if the first broker goes down after the client started publishing, the client simply aborts instead of failing over to the second broker. This was easily reproducible for me. Is this expected behavior? Or, am I missing something?

Wed Feb 08 01:58:25 2012 LCONS [...] cpan.org - Correspondence added

Net::STOMP::Client works as designed: the (partial) failover support for the URI that you can give in the new() method only works inside this method and gives you some failover support (only) at the TCP connection level. Once the connection is established, the module will never try to re- connect and/or re-play some commands to the STOMP server. No black magic here. The rationale behind this decision is that the module does not have the knowledge of what the broker did so it cannot decide what to re-play or not. Two examples: maybe you use transactions so the module would need to implement the broker's transaction logic to find out what to re-play or not; maybe the module did send something (it reached the outgoing TCP socket) but the broker did not receive it or did not process it before failing... The bottom line is that it is extremely complex to have a bulletproof recovery strategy that works in all cases. Since you know your application logic, you know better what to re-play or not in case of failure.

Wed Feb 08 01:58:26 2012 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 08 01:58:27 2012 LCONS [...] cpan.org - Status changed from 'open' to 'rejected'

Wed Feb 08 02:29:10 2012 http://buchireddy.blogspot.com/ - Correspondence added

From:

Buchi Reddy

Ok. Thanks for the reply. I think it would be clear if this is mentioned as few lines in documentation. I was also thinking about the complications involved in doing this completely, and hence asked if this is expected. On Wed Feb 08 01:58:25 2012, LCONS wrote: Show quoted text

> Net::STOMP::Client works as designed: the (partial) failover support

for Show quoted text

> the URI that you can give in the new() method only works inside this > method and gives you some failover support (only) at the TCP

connection Show quoted text

> level. > > Once the connection is established, the module will never try to re- > connect and/or re-play some commands to the STOMP server. No black

magic Show quoted text

> here. > > The rationale behind this decision is that the module does not have

the Show quoted text

> knowledge of what the broker did so it cannot decide what to re-play

or Show quoted text

> not. Two examples: maybe you use transactions so the module would need > to implement the broker's transaction logic to find out what to re-

play Show quoted text

> or not; maybe the module did send something (it reached the outgoing

TCP Show quoted text

> socket) but the broker did not receive it or did not process it before > failing... > > The bottom line is that it is extremely complex to have a bulletproof > recovery strategy that works in all cases. Since you know your > application logic, you know better what to re-play or not in case of > failure.

Wed Feb 08 02:29:11 2012 The RT System itself - Status changed from 'rejected' to 'open'

Wed Feb 15 08:41:13 2012 LCONS [...] cpan.org - Correspondence added

The documentation has been augmented wrt failover support. This will appear in the next version. It will contain: FAILOVER The "uri" option of the new() method can be given a complex URI indicating some kind of failover, for instance: "failover:(tcp://msg01:6163,tcp://msg02:6163)". This must use the ActiveMQ syntax (see <http://activemq.apache.org/failover-transport-reference.html>) and only some options are supported, namely: "backOffMultiplier", "initialReconnectDelay", "maxReconnectAttempts", "maxReconnectDelay", "randomize" and "useExponentialBackOff". When specified, these failover options will be used only inside the new() method (so at the TCP connection level) and not elsewhere. If the broker later fails during the STOMP interaction, it is up to the program author, knowing the logic of his code, to perform the appropriate recovery actions and eventually reconnect, using again the new() method.

Wed Feb 15 08:41:14 2012 LCONS [...] cpan.org - Status changed from 'open' to 'resolved'

Tue Feb 28 10:00:59 2012 LCONS [...] cpan.org - Fixed in 1.5 added