Not clear how reconnect effects subscriptions

[dynajoe]

I've configured my connection to RabbitMQ and set up queues without auto subscription.

      queues: [{
         name: 'device.inbound.q',
         autoDelete: false,
         subscribe: false,
         durable: true,
         noBatch: true,
         deadLetter: 'device.inbound.dead.ex',
         limit: 20,
         exclusive: false,
         noAck: false,
      }]

(I don't auto subscribe because my handlers aren't registered at configuration time)

Sometime later I start a subscription like so:

rabbit.startSubscription('device.inbound.q')

All is working fine until my connection to the RabbitMQ server is lost for whatever reason (in my case usually a restart of the rabbitmq service). At this point my subscription is not re-established and I need to restart my process in order to start receiving messages again.

How should this be handled? Should the subscriptions be automatically restarted? Do I need to keep track of the started subscriptions and restart them?

[dynajoe]

I figured I'd try to call startSubscription for my queue after it reconnects iff the subscription has been started.

   Rabbit.on('connected', () => {
      if (subscriptionStarted) {
         Rabbit.startSubscription('device.inbound.q')
      }
   })

When adding the rabbit.on('connected', fn) handler it seems to change the behavior of publishing after disconnects. I start receiving this message:

Potentially unhandled rejection [17] Error: Publish took longer than configured timeout
    at null.<anonymous> (/Users/joe/code/wascally-test/node_modules/wascally/src/exchangeFsm.js:76:15)
    at Timer.listOnTimeout (timers.js:92:15)```

[arobson]

@joeandaverde I think this is likely related to issue #119 - wascally really should re-subscribe to any queues that it had subscriptions to during a disconnect. Right now, any queues defined with subscribe set to true already behave this way. Anything you manually start the subscription to doesn't.

[yamii]

I'm using the library rabbus which handles my request-respond queue creation, bindings and the like.

By default it uses subscribe:false for queue settings and I set my replyQueue to use subscribe:true.

I do this after reconnection:

rabbit.connections.default.connection.on( 'aquired', () => {
  // loop through my queues except replyQueue
  loop
    rabbit.startSubscription( <queueName > )
  endOfLopp
} );

it seems to be working fine in my end. I only do startSubscription when I'm sure that rabbit is reconnected and not the first connection. And I didn't have this error below:

Potentially unhandled rejection [17] Error: Publish took longer than configured timeout
    at null.<anonymous> (/Users/joe/code/wascally-test/node_modules/wascally/src/exchangeFsm.js:76:15)
    at Timer.listOnTimeout (timers.js:92:15)

[arobson]

@joeandaverde @yamii - wascally is no longer actively maintained, instead, check out rabbot. Rabbot does "remember" the subscription status when connectivity was last established and try to re-subscribe once the connection and queue are in place.