Automatic reconnection works only once (except for Apache Apollo)

[sahilm]

1. I was testing out the automatic reconnection feature which should kick in if the client cannot connect to the broker.
2. With a simple consumer like this:

require 'bundler/setup'
require 'stomp'
require 'json'
require 'pp'

hash = { :hosts => 
  [
   { :login => "admin",
     :passcode => "password",
     :host => 'localhost', 
     :port => 61613 
   }
  ],
}

client = Stomp::Client.new(hash)

# subscribe
client.subscribe("/queue/foo") do |message|
  if message.headers["content-type"] =~ /json/
    pp JSON.parse(message.body)
  else
    pp message.body
  end
end
Kernel.trap(:INT) {
  client.close
  puts "Recieved term, stopping..."
  exit 0
}
loop do
  sleep(1)
  puts "."
end

I ran the test by shutting down the broker while the consumer was running and then subsequently bringing it back up.

1. For RabbitMQ (2.8.6.1) and ActiveMQ (5.7.0) on Mac OS X 10.8.2 and CentOS 6.3, automatic reconnection works only once. That is, the consumer reconnects the first time I bounce the broker but not on subsequent restarts.
2. Surprisingly, automatic reconnection seems to work flawlessly with Apache Apollo (1.4) on Mac OS X 10.8.2.

[sahilm]

Periodically publishing to a hearbeat topic seems to trigger the reconnect logic. Tested with RabbitMQ 2.8.6.1

require 'bundler/setup'
require 'stomp'
require 'json'
require 'pp'

hash = { :hosts => 
  [
   { :login => "guest",
     :passcode => "guest",
     :host => 'localhost', 
     :port => 61613,
   }
  ]
}

client = Stomp::Client.new(hash)

client.subscribe("/queue/foo")   do |message|
  if message.headers["content-type"] =~ /json/
    pp JSON.parse(message.body)
  else
    pp message.body
  end
end

Kernel.trap(:INT) {
  client.close
  puts "Recieved term, stopping..."
  exit 0
}

loop do
  sleep 1
  begin
    client.publish("/topic/heartbeat","beat")
  rescue Stomp::Error::NoCurrentConnection => e
    puts "Retry in 1s"
    sleep 1
    retry
  end
end

[gmallard]

Hi - I could not recreate this here with a quickly setup test (using AMQ) on Ubuntu, however will continue to experiment a bit.

What gem version are you running?

Why does your example require 'bundler/setup? It seems unused.

What Ruby version? (Should not matter, but ....).

With AMQ are you using 'stomp://' or 'stomp+nio://'? AMQ 5.7.0 has some ragged edges when using nio.

Are your brokers on the same machine as the client?

If you could enable a call back logger (see the examples) for one of these tests, and pastebin the output that might be helpful.

Thanks, Guy

[gmallard]

FYI - I have not been able to recreate this in a variety of tests and environments.

Servers used: AMQ 5.7.0 and RabbitMQ 2.8.4. Both servers on Linux (Ubuntu). I did not test against Apollo, but am confident the results would be the same.

Client environments used: Ubuntu 11.10, Win 7, OSX 10.8.0.

In all these tests reconnecting at least 3 times succeeds.

One point to note: give the 'subscribe' parameters you use above, even if you do reconnect, it is likely that there will be nothing to receive from /queue/foo. You need something other than :ack => "auto" to prevent that.

[sahilm]

Thank you very much, Guy. I've been a tied up since the past few days. I'll be sure to follow up with more comprehensive test results and data ASAP.

[gmallard]

Any updates on this? Just curious ......

Thanks, Guy

[gmallard]

This issue report is ancient. I am going to close this, with no resolution.

Please re-open this issue including code that can reproduce the problem when you have developed that code.

[pic]

I'm experiencing the same with AMQ 5.5.1 . Gem version is 1.2.8 I can constantly reproduce the problem with these steps:

• start AMQ
• start my consumer, it connects immetiately, all fine
• stop AMQ, consumer starts to try to reconnects
• start AMQ again, consumer reconnect, all fine
• stop AMQ, consumer dies, exception is in lib/client/utils.rb , line 100, message is nil

I can provide more info, I can test with AMQ 5.7.0 too, please let me know

[pic]

same behaviour with AMQ 5.7.0

[gmallard]

Thanks. With your description, this can actually be recreated. Reopened.

[pic]

thanks to you, tell me if you need more info

[gmallard]

Thanks for the hint about utils.rb, line 100. That was being masked in previous attempts to recreate this.

Closed: 3198504