mxriverlynn / rabbus

A micro-service bus with built-in messaging patterns, for NodeJS and RabbitMQ
116 stars 26 forks source link

Req/res queues remain after disconnect #24

Closed matmar10 closed 8 years ago

matmar10 commented 8 years ago

Steps to reproduce:

Actual behavior: req/res temporary queues remain Expected behavior: req/res temporary queues should be destroyed if no messages exist

Maybe there is an option for this I'm not aware of to destroy req/res queues on shutdown?

screen shot 2016-05-12 at 11 07 32 pm

matmar10 commented 8 years ago

Ping.

mxriverlynn commented 8 years ago

sorry for the delay on this - i had been on projects that did not use rabbus, for almost a year now. i've been looking into this problem today, and will hopefully have this fixed in the next release of rabbus (soon)

matmar10 commented 8 years ago

Thanks Derick! This would be a huge win for the projects we're using this in.


Matthew J. Martin

email: matthew.mar10@gmail.com mobile: +1.415.601.4879 G+: Matthew.Mar10 | Skype: MatMar10

On Wed, Aug 17, 2016 at 1:20 AM, Derick Bailey notifications@github.com wrote:

sorry for the delay on this - i had been on projects that did not use rabbus, for almost a year now. i've been looking into this problem today, and will hopefully have this fixed in the next release of rabbus (soon)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/derickbailey/rabbus/issues/24#issuecomment-240173148, or mute the thread https://github.com/notifications/unsubscribe-auth/AABOB41CTYIlc_-VNEkXjNq0u7zLCQqoks5qgfFIgaJpZM4Idua5 .

mxriverlynn commented 8 years ago

i meant to update earlier today, and got sidetracked with things...

after digging more today, i figured out the problem is with message producers. if you only specify the exchange through which a message should be produced, it will default to having a no-name queue but use the rest of the "default" settings for the queue in that pattern (Publisher, Requester, or Sender).

a no-name queue will have a queue name generated by RMQ. and the lack of auto-delete comes from the "default" settings that I use for the producers.

oops.

i found a workaround for now, and a fix for the next release.

the workaround has it's own set of problems, though.

in the configuration for a message producer, you can provide a queue configuration even if you don't need one, and set the autoDelete to true.

for example:

new Publisher({
  exchange: "some.ex",
  queue: {
    name: "junk.queue",
    autoDelete: true
  }
});

this will cause the queue to be created and bound to the exchange, though. when the producer shuts down, the queue will be deleted and all the messages in it will go away... but that can be problematic for high throughput producers - taking up a bunch more memory and resources on the RMQ server.

the real fix is in the works in my "rabbot" branch of the code. i have this fix in place, basically, but i'm running into failing tests right now. i had to make changes to the code without tests, to figure out how the fix should work - and now i have to update the tests and related code to get it all back in working order. hopefully that will happen this coming Thursday (the 18th) when i'm back at my client office for my project that needs this.

mxriverlynn commented 8 years ago

this issue should be fixed in the latest v0.8.0 release, which also updates rabbus to use rabbot instead of wascally