[rabbitmq-discuss] share a pre-built queue

Tim Watson watson.timothy at gmail.com
Fri Oct 5 08:05:07 BST 2012


On 4 Oct 2012, at 14:22, Prabodh Upreti <prabodh.upreti at vce.com> wrote:

> Perfect.  Hope this is my last question.
> I will have many clients interacting with the broker.  I need to really
> control what they can do with the system.  I am planning to publish filters
> they can subscribe to via REST interfaces.
> 1.  How can I give them permissions so they can only create exclusive = true 
> queues.

Afaik that is not currently possible, so you'll have to enforce this in your application(s). Ironically if the queues were not exclusive then you could delegate the queue.declare to a utility layer in the rest service and simply return the queue name, but of course you'd then have to deal with monitoring the client(s) and deal with disconnects yourself. There are probably several variations on this theme too, with intermediary clients or brokers handling the upstream connectivity and so on, not to mention the potential to use federation and/or shovel  to achieve some of this middle man's role. Ultimately though, I suspect that the complexity outweighs the benefits every time.

Personally I would take the reduced complexity of exclusive queues bound to the topic exchange and live with the potential loophole, especially if I'm in control of the client code base(es). If it is important to try hard to avoid letting clients create queues with the wrong parameters, then the best approach IMO would be to write a simplified high level API that sits on top of the AMQP client and (have consumers) code the clients against that, hiding the details of the connection and to some extend the underlying technology from them.

> 2.  The reason I was going with the pre-built queue was so that I could have
> 5 keys bound to the FIXED named queue and they would not need to worry about
> binding all the keys to their temp queue.  If they can't do that then I just 
> have to inform them about the keys so they can use the right ones.  Please
> let me know if there is a better way to manage this.

That sounds like a workable Domitian to me. Getting the keys from a service call or via an additional application wide control channel are both pretty common approaches in the integration space.

> Once again thank you both for you feedback.
> regards
> prabodh
> --
> View this message in context: http://rabbitmq.1065348.n5.nabble.com/share-a-pre-built-queue-tp22319p22362.html
> Sent from the RabbitMQ mailing list archive at Nabble.com.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

More information about the rabbitmq-discuss mailing list