Closed johntdyer closed 9 years ago
@johntdyer
Sorry for the delay. When this message hit my private mail, it went to a spam bucket. Not sure why.
Status: (I can recreate) accepted. It appears the default 10 second connection timeout broke this.
Usage notes for you: a) If you can use 1.3.1, this will probably be OK for you at present. b) Or, if you can use a Stomp#Connection, this will probably be OK for you at present. c) Regardless, you absolutely must add to the connection hash the parameter:
:max_reconnect_attempts => #
and specify some non-zero number. It defaults to zero, which in turn effectively means 'do not retry'.
d) Food for thought: your 'initial_reconnect_delay' (5000) is a fairly long time, it seems excessive to me. It is in seconds (not milliseconds). And is 83min20sec (appx).
So, this is on the to do list. Targeted for the next gem version.
Regards, G.
c) Above is wrong / missated. 0 should be OK for max_reconnect_attempts.
Thanks, this helped
On Tue, May 13, 2014 at 11:20 AM, Guy M. Allard notifications@github.com wrote:
c) Above is wrong / missated. 0 should be OK for max_reconnect_attempts.
Reply to this email directly or view it on GitHub: https://github.com/stompgem/stomp/issues/98#issuecomment-42969191
Comments for now .....
Stomp#Connection use is not affected.
The flaw is triggered by the condition:
:initial_reconnect_delay > :start_timeout
It can also be triggered when the total time spent attempting fail overs exceeds :start_timeout.
The problem can be totally bypassed by using the following in the Client's connect hash:
:start_timeout => 0
The difficulty is a fundamental clash between:
Final resolution is TBD at present. Resolution is very likely to favor retention of previous fail over logic in almost all cases.
Considering 4 possible resolutions:
Any others?
Any preferences or other thoughts?
If there are no scenarios where :initial_reconnect_delay > :start_timeout
is meaningful then throw an exception when this condition is detected, perhaps?
Thoughts?
This should be fixed in v1.3.4.
Specifically:
847d346
7474222
Perhaps several other commits in the 1.3.3 -> 1.3.4 chain.
I am trying to two brokers w/ the following connection hash
however the first broker in this case is down, shouldn't it immediately try the second?