Reply queue message not ack'ed on req-resp pattern

[pocheng]

On request-response pattern, the reply queue has messages piled up not .ack (). Saw previous issue where this bug should had been fixed. But it is appear on my end.

Can anyone shed some light on this? Thanks.

I am using

• wascally 0.2.7,
• node.js 0.10.36
• rabbitMQ 3.5.4

server.post ('/test', function (req, res, next) {
  var body = req.body;
  rabbit.configure (local).then (function () {
    rabbit.request (exchange, { 
      routingKey:"",
      type: "reqres.type",
      body: body
    })
    .then (function (response) {
      console.log ('received response...'.success);
      console.log (response);
      response.ack ();
      res.send (); 
      return next ();
    })
    .then (undefined, function (err) {
      next (new restify.errors.BadRequestError (err));
      handleError (err);
    });

    rabbit.handle("reqres.type", function(message) {
      try {
        console.log ('');
        console.log ('receiving msg..'.success);
        console.log(message);

        message.reply({
          foo: "replied bar"
        });
      } catch(err) {
        message.nack();
      }
    });

    rabbit.startSubscription ('user.create');
  })
  .then (undefined, handleError);
});

receiving msg..

{ fields: 
   { consumerTag: 'amq.ctag-Xb3S6BUP9Kos6geuTPWMhw',
     deliveryTag: 1,
     redelivered: false,
     exchange: 'user',
     routingKey: '' },
  properties: 
   { contentType: 'application/json',
     contentEncoding: 'utf8',
     headers: {},
     deliveryMode: undefined,
     priority: undefined,
     correlationId: '',
     replyTo: '82547150-3758-11e5-a17f-493c531269a7.response.queue',
     expiration: undefined,
     messageId: 'ed3d85b0-3758-11e5-a17f-493c531269a7',
     timestamp: undefined,
     type: 'reqres.type',
     userId: undefined,
     appId: '',
     clusterId: undefined },
  content: <Buffer...>,
  body: { foo: "bar"},
  ack: [Function],
  nack: [Function],
  reject: [Function],
  reply: [Function],
  type: 'reqres.type' }

received response...

{ fields: 
   { consumerTag: 'amq.ctag-LWBka6t32Q5rbIPkQ26CtQ',
     deliveryTag: 37,
     redelivered: false,
     exchange: '',
     routingKey: '82547150-3758-11e5-a17f-493c531269a7.response.queue' },
  properties: 
   { contentType: 'application/json',
     contentEncoding: 'utf8',
     headers: { sequence_end: true },
     deliveryMode: undefined,
     priority: undefined,
     correlationId: 'ed3d85b0-3758-11e5-a17f-493c531269a7',
     replyTo: '82547150-3758-11e5-a17f-493c531269a7.response.queue',
     expiration: undefined,
     messageId: undefined,
     timestamp: undefined,
     type: 'reqres.type.reply',
     userId: undefined,
     appId: undefined,
     clusterId: undefined },
  content: <Buffer ...>,
  body: { foo: 'replied bar' },
  ack: [Function],
  nack: [Function],
  reject: [Function],
  reply: [Function],
  type: 'reqres.type.reply' }

[arobson]

@pocheng - I don't think the example code you have will work, and I'd like to suggest some improvements as well.

Move your configuration out of the request block

I would move configuring the topology into a function that happens as your service starts up and only start the HTTP server after it's in place. This is the pattern we use for our services and it works well. If connectivity is lost, wascally will automatically re-establish the entire topology for you when it re-connects. There is no need to re-call configure.

Bug in the response handler?

You have the line: console.log ('received response...'.success); which might throw an exception. I usually recommend wrapping message handling blocks in try/catch so that you consistently ack or reject messages.

Let me know if you are continuing to see this issue. I haven't been able to reproduce it but there may be other differences in how I've set up my topology.