Closed matmar10 closed 8 years ago
Ping.
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)
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 .
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.
this issue should be fixed in the latest v0.8.0 release, which also updates rabbus to use rabbot instead of wascally
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?