[rabbitmq-discuss] Missing features making me look at moving off RabbitMQ
matthias at rabbitmq.com
Sat Oct 30 02:46:55 BST 2010
Christian Legnitto wrote:
> Just thought I'd send a note detailing why I am investigating moving
> off RabbitMQ.
Thanks for letting us know. Let's see whether we can help you...
> -- Built-in way to deal with the "slow consumer" problem
> * For pulse, it is entirely conceivable that consumers will check in
> once and perhaps go away for weeks (or maybe forever) * Ideally
> support would be configurable and similar to
RabbitMQ has several ways of dealing with consumers that go away:
- exclusive queues - go away when the connection dies
- auto-delete queues - go away when the last consumer disappears
- queues with leases - go away when unused for some time
- per-queue message ttl (in the next release) - messages expire after a
per-queue configured ttl
Would any of these work for your use case?
> -- Built-in HA
> * It'd be nice to not have to cobble together multiple pieces to get
Instead of "cobbled together" I'd like to think of it as "using a
combination of tried & trusted best-of-breed products" ;)
We are working on better and more integrated HA. Meanwhile, the
instructions for the existing active/passive HA may look a bit
daunting, but it's actually not that hard to set up.
> -- Support custom authentication schemes
> * I'd like to be able to hook authentication to different backends
> (like ldap, use bugzilla for auth, etc) * I need this as I don't want
> to maintain lists and want to give permissions based on ldap groups
This has been requested a few times but hasn't yet bubbled up far enough
our priority list to make it into the code base.
Tweaking the code s.t. it supports your particular authentication scheme
should only take a few hours. Implementing a more generally
applicable and pluggable mechanism would take a few days.
> -- Support message-level permissions
> * It'd be nice for a publisher to be able to include a security token
> and have the broker decide to vend to a consumer or not based on it
> * Haven't really thought about this in-depth yet, but the problem we
> are trying to solve is publishing multiple-tiers of
> security-sensitive information where the message content itself
> determines who should see it
That sounds like a pretty hard problem. Are there any messaging systems
out there that do something close to what you need here?
> -- Support for WebSockets
> * It'd be nice for there a plugin to support websockets * More
> important for Mozilla as most tools are web-based *
I'd be surprised if some websockets support didn't find its way into
a rabbit plug-in soon.
Meanwhile, would any of existing Rabbit plug-ins/extensions for
messaging-over-HTTP, such as the jsonrpc-channel
rabbithub (http://github.com/tonyg/rabbithub) work for you?
> -- Public bugtracker
> * Be nice to file bugs, learn from other's bugs, etc
There is no official public rabbit bug tracker but you can (and people
occasionally do) file bugs in the rabbit bug trackers on github, ubuntu,
debian, etc. That doesn't give you much insight into what the rabbit
team is working on though, which is what I think you are after.
> * I understand there is a private one. Can you just set all existing
> bugs to restricted and provide public access? All new bugs could be
> public and as soon as old bugs are vetted you could open them up
Something like that will probably happen eventually. The issue tracking
system plays a pivotal role in the work of the RabbitMQ team. We have
more than 2500 bugs recorded in it, touch about 30 bugs a day and open
~100 new ones per month. So there's a lot going on, which of course
would make it an incredibly valuable resource for the community. But
because it is so important to the rabbit team any fundamental changes to
it require careful consideration.
> -- Public roadmap
> * Very critical when you are basing your entire organization on a
Our to do list so far has resisted attempts to condense it into a
roadmap that can be navigated without a personal guide ;) And our plans
are quite fluid since the prioritisation of work items is often finely
balanced and can change radically with just a single user request (e.g.
for pluggable authentication ;), bug report, etc.
Having said that, we are always happy to discuss our current plans with
potential customers / users. Shall I give you a ring?
> * Management console / API was on this list, then all of a
> sudden someone started working on it (thanks!), but it would have
> been nice to know it was coming
That is one example of the fluidity of our plans. Improvements to
management had been on our todo list for a long time. It took a
combination of various factors and events to push it near the top of our
priority list. Once it had ended up there, exploratory work got underway
very quickly. The first line of code was written on July 12th. We
announced it to the world less than four weeks later, on August 6th,
once we were confident it would make it into the product soon.
So if it looked like rabbitmq-management appeared out of the blue then
that is because it did :)
Most features / fixes we decide to work on make it into the product
within 1-2 months. Or they get parked or abandoned. For the few items
that take several months we could perhaps be a bit more vocal about
their progress. But doing so always carries the risk of disappointing
people when the features subsequently get delayed or abandoned.
More information about the rabbitmq-discuss