Duplicate Durable Stomp Subscription handling

[cfergus]

Existing question, with content duplicated below : http://stackoverflow.com/questions/23699711/how-can-i-handle-a-duplicate-durable-stomp-subscriber/23721276?noredirect=1#comment36692273_23721276

I have multiple Ruby processes that start up and try to connect to a topic via a durable subscriber using Stomp.

The first process succeeds, and reads messages (yay).

Subsequent processes fail, and repeatedly try to reconnect.

How can my processes discover that the durable subscriber is already connected, and quit trying to connect?

Possible desired code snippet:

begin
  stomp_client.subscribe()
rescue ClientAlreadySubscribedException
  puts "No problem, let's keep doing our other code"
end

Environment:

Ruby 1.9.3 stompgem 1.3.2 activemq 5.9.0 Code to replicate issue:

require 'stomp'

# Connect with durable subscription
hash = {
  hosts: [
    { host: "localhost", port: 61613, ssl: false }
  ],
  connect_headers: {
    :"client-id" => "durableRubyTest"
  }
}
stomp_client = Stomp::Client.new( hash )

stomp_client.subscribe "/topic/durable.test.dev",
    {"activemq.subscriptionName" => "devtest" } do |msg|
  puts "Message! "
  puts msg.inspect
end
puts "Connected to stomp, waiting for messages..."
stomp_client.join

Then, run this code twice, ie in two different terminals.

[gmallard]

Many thanks for the detailed description and code. Most problem reports do not include any detail whatsoever.

Having said that, I agree with Tim: it is your application's responsibility to check for ERROR frames wherever they may be received.

In your example, the first real problem is not with SUBSCRIBE.

Your code (in the second terminal) fails on the initial CONNECT. You need to detect and deal with that broker emitted ERROR frame.

Ref:

https://gist.github.com/gmallard/dcccd49fc2ae422152f2

[gmallard]

Closed, not a gem defect.