reconnect delays not always honoured

[ripienaar]

If I make a deliberate mistake here - not specifying :"accept-version" header - the reconnect delays and backoffs arent honoured:

class Logger
  def on_connectfail(params=nil)
      puts "%s: failed to connect: %s" % [Time.now.to_i,  params[:cur_host]]
  end
end

connection = {:hosts => [ {:login => "rip", :passcode => "secret", :host => "stomp", :port => 6163} ],
              :initial_reconnect_delay => 0.1,
              :max_reconnect_delay => 30,
              :use_exponential_back_off => true,
              :back_off_multiplier => 2,
              :max_reconnect_attempts => 10,
              :logger => Logger.new,
              :connect_headers => {:host => "test"}}

@connection = Stomp::Connection.open(connection)

p @connection.connection_frame

% ruby test.rb
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198528: failed to connect: stomp
1368198529: failed to connect: stomp
1368198529: failed to connect: stomp
1368198529: failed to connect: stomp
/home/rip/.gem/gems/stomp-1.2.9/lib/connection/utils.rb:138:in `socket': Maximum number of reconnection attempts reached (Stomp::Error::MaxReconnectAttempts)

you can see there is no backoff of anything here

so the settings are for reconnections, but I think this should also apply in the initial connetion setup?

[gmallard]

I believe what you have uncovered is ..... not the bug you think you have uncovered. Please read on.

There is a bug that is triggered even before the reconnect attempts occur.

In this case:

• You have .... lied to me about Stomp 1.1 .... You have said
• Yes I want 1.1 (host header is there)
• But no I do not want 1.1 (missing accept-version header)

That is a protocol error on your part.

What should happen is this:

• You should receive exception Stomp::Error::ProtocolErrorConnect
• No (zero) retries should be performed by the gem in this case

The gem handles this correctly if :reliable => false. This bug is with :reliable => true being specified.

I agree that reconnect delays etc. should be honored during the first connect attempt. And in fact they normally are. Try this with your example:

• Add an appropriate "accept-version" header
• Specify a bogus port, that nothing listens to
• Change Time.now.to_i to Time.now.to_f for more clarity

Re-run that example. You should see the times increase appropriately. Back offs are good e.g.:

time ruby -I $STOMPLIB reconnopen.rb
1368206597.0774972: failed to connect: localhost
1368206597.1783278: failed to connect: localhost
1368206597.379195: failed to connect: localhost
1368206597.780118: failed to connect: localhost
1368206598.580965: failed to connect: localhost
1368206600.1819065: failed to connect: localhost
1368206603.3828065: failed to connect: localhost
1368206609.783764: failed to connect: localhost
1368206622.5846832: failed to connect: localhost
1368206648.1856654: failed to connect: localhost
1368206678.186619: failed to connect: localhost
/ad3/gma/stomp-repos/stompgem/lib/connection/utils.rb:142:in `rescue in block in socket': Maximum number of 
reconnection attempts reached (Stomp::Error::MaxReconnectAttempts)
...
...
real    1m21.166s
user    0m0.040s
sys 0m0.024s

Ignore the line number difference in utils.rb between my example and yours.

Your thoughts?

[ripienaar]

Yeah, I know it works sometimes - certainly does when I give it full correct properties etc - I assumed there were some code paths that didn't maintain the needed counters but your explanation sounds better.

So I guess this is a case of a bug related to failing better on config error and perhaps with some better messages

[gmallard]

See e9d59a2

This will be in the next gem release.