#9385 Please turn on: server-named queues for fedora-messaging
Opened 7 months ago by astepano. Modified 3 months ago


Please help me understand, why fedora-messaging doesn't support Server-named Queues?
Is there any decisions that this feature is turned off?


In AMQP 0-9-1, the broker can generate a unique queue name on behalf of an app. To use this feature, pass an empty string as the queue name argument... 

Moreover, in tutorial it is suggested to use empty name for queue:


Firstly, whenever we connect to Rabbit we need a fresh, empty queue. To do it we could create a queue with a random name, or, even better - let the server choose a random queue name for us. We can do this by supplying empty queue parameter to queue_declare:
result = channel.queue_declare(queue='')

According to https://fedora-messaging.readthedocs.io/en/latest/quick-start.html#fedora-s-public-broker queue name is required.

From this decision errors like this emerge:


Please turn this feature ON. Because it is part of standard. Otherwise, please help me understand why it turned OFF, and maybe update document: https://fedora-messaging.readthedocs.io/en/latest/quick-start.html#fedora-s-public-broker with explanation.

Thank you!

Metadata Update from @pingou:
- Issue tagged with: rabbitmq

7 months ago

Metadata Update from @mohanboddu:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: medium-gain, medium-trouble, ops

7 months ago

I think it was considered by @jcline when designing the public broker. I'm not sure why he decided on client-specific, uuid-based queue names. Perhaps for permissions or garbage-collecting reasons. Jeremy, could you chime in?

Metadata Update from @abompard:
- Issue untagged with: medium-gain, medium-trouble, ops
- Issue priority set to: Needs Review (was: Waiting on Assignee)

7 months ago

I'm hazy on the choices I made, and of course there may not have been a strong reason at all.

If I remember correctly it was mostly because I assumed folks would overwhelmingly want their queues to survive longer than an AMQP channel and forcing them to name the queue would avoid the "I don't understand why all my messages disappeared when my channel closed" type complaints?

As far as a know the broker does support server-generated names, but obviously the permissions restrictions might clash with whatever names it generates. I probably reasoned it was just as easy to generate a name client-side, but maybe that wasn't such a good idea.

If it's something folks want it's probably as easy as figuring out the RabbitMQ name generation and adding the appropriate access controls/garbage collection for such names.

@jcline thank you for the input.

I need to add: server-named queues for fedora-messaging + in scope of access to fedora-s-public-broker. I am totally support to disable server generated queues for private virtual host.

However, this feature It would be useful to access publicly accessible virtual host.

Such queues already have garbage collector + limit in size + inactivity cleanup.

For public virtual hosts, I think it is OK for consumers to generate each time new UUID + set exclusive = true. This is useful feature.

If I specify queue name as empty string '' broker creates a queue!
But, fedora user cannot access it:

Error: Channel closed by server: 403 (ACCESS-REFUSED) with message "ACCESS_REFUSED - access to queue 'amq.gen-fQdrfUzszithmUDuGB1Cgw' in vhost '/public_pubsub' refused for user 'fedora'"

This is because fedora user has access to queues that have distinct UUID format.
But, queue was created: amq.gen-fQdrfUzszithmUDuGB1Cgw.


Queue names *must* be in the normal UUID format

Some kind of inconsistency, I think.

Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: medium-gain, medium-trouble, ops

7 months ago

@astepano would you be willing to write a PR to move this forward? or figure out what format the named queues are so we can adjust cluster policy for them?

Login to comment on this ticket.

Boards 1
ops Status: Backlog