How to properly close / release connections

[mehcode]

Running a simple file causes node to hang and never terminate normally.

require("wascally");

Save that line as index.js and run as node index.js. Node hangs and doesn't terminate.

[mehcode]

Poked at it for a few minutes and found that calling clearAckInterval allows node to exit normally.

var rabbit = require("wascally");
rabbit.clearAckInterval();

---

I'm not aware of why this interval is needed but can we start the interval after establishing at least one connection and clear it after closing all connections?

[mehcode]

One more thing. If I've called .configure, no amount of .close or .clearAckInterval will get node to exit normally. Any ideas?

[arobson]

@mehcode - what's the use case? If you want the process to exit, you can always just process.exit(). Wascally is designed for writing services that communicate via Rabbit. "exiting normally" isn't something we want those to do unless there's an exception.

[mehcode]

I just want to publish-and-forget messages. It's a bit strange when my quick node script that I write up to send some messages just sits there and hangs even after closing all connections. In the end, I'll be sending messages while handling an HTTP request. So terminating really isn't an issue.

However, I feel it's just good manners from an API perspective to allow the user to clean up. If .close isn't good (because a reconnect might be desired) then perhaps adding a .quit method. I've always though that process.exit feels a bit hack-ish.

---

On another note, after doing some more reading of the issues I'd like to make the response queue opening for handling .request an optional feature that I can disable during .configure.

[arobson]

@mehcode - you can call process exit after the promise returned from close has resolved. I don't know why you feel that that's hack-ish, I think it actually makes a script's behavior clearer.

There's already a feature to do what you described: https://github.com/leankit-labs/wascally#no-automatic-reply-queue

[mehcode]

@arobson I'm just trying to understand things here.

rabbit.publish("ex-1", "type", {id: 1}).done(function() {
  rabbit.close().done(function() {
    process.exit();
  });
});

If I run that code my process exits too soon and the worker never gets the message.

[mehcode]

Okay. I've got it figured out.

For future reference:

rabbit.publish("ex-1", "type.name", {id: 3}).done(function() {
  setImmediate(function() {
    rabbit.close().done(function() {
      rabbit.clearAckInterval();
    });
  });
});

I created some helper functions to make it easier in my project (MIT license)

export function close() {
  return new Promise((resolve) => {
    rabbit.close().done(() => {
      rabbit.clearAckInterval();
    });
  });
}

export function publish(type, msg) {
  return new Promise((resolve) => {
    rabbit.publish("ex-1", type, msg).done(() => {
      setImmediate(resolve);
    });
  });
}

Usage then becomes:

util.publish("type.name", {id: 1}).then(function() {
  util.close();
});

[Rob--W]

Why is this issue closed? The bug is still present.

I'm using wascally to send data to RabbitMQ. In unit tests, I don't care whether the destination is a REST API or a RabbitMQ endpoint, so I'm only inspecting the data that would be send. I do that by mocking the module that publishes the data.

But because of this bug, the test runner never exits because wascally eternally keeps around a useless timer. Why should this timer be initialized this early? Can't you lazily initialize the timer, or use counting to see whether the timer is needed (and disable the timer if there are no outstanding ACKs)?

[mxriverlynn]

not sure why it was closed, but there's discussion around this same issue in #112 with a workaround posted at the bottom.

[d-nation]

@mehcode 👍 Thanks.