Announcement Announcement Module
No announcement yet.
Advice needed on binding a new queue to a fanout-exchange Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Advice needed on binding a new queue to a fanout-exchange


    I am new to RabbitMQ and would be keen to get some advice on my first use-case.

    My application is an online game and an early requirement is when a new game server instance is booted it will bind a queue to a fanout-exchange. This fanout-exchange is used by game clients to send a message to all active game servers.

    So far I have this configuration:

    <rabbit:connection-factory id="rabbitConnectionFactory"
    		host="{}" username="{broker.hub.username}" password="{broker.hub.password}" />
    	<rabbit:admin id="amqpAdmin" connection-factory="rabbitConnectionFactory" />
    	<rabbit:queue id="clientBroadcastQueue" auto-delete="true" exclusive="true" durable="true"/>
    	<fanout-exchange id="gameHouseFanoutExchange" name="{}"
    		durable="false" xmlns="">
    			<binding queue="clientBroadcastQueue"/>
    	<channel id="joinHub" />
    	<rabbit:template id="amqpTemplate" connection-factory="rabbitConnectionFactory"
    		exchange="{}" />
    I have used an anonymous queue because I want a unique queue name (guess I could generate something uniquely myself?) and I also want properties of auto-delete="true" exclusive="true" durable="true". At the moment this gives me an error: Configuration problem: Anonymous queue cannot specify durable='true', exclusive='false' or auto-delete='false'.

    I guess I'm not going about this the right way. Any pointers would be great.



  • #2
    I have not used AMQP in a while but here is what comes to mind.
    If the queue is anonymous it means that its only known to a component at the time of its creation. Next time the same configuration starts its going to be a new anonymous queue which means that one created before would be just sitting there. So making anonymous queue durable is meaningless. Because the whole purpose of durable queue is to be able to reconnect to it later and retrieve all the messages that survive the restarts. The rest of the attributes would have a similar explanation.
    So i'd suggest generate a unique name and don't make it anonymous.


    • #3
      Thanks Oleg, that makes sense. It is all becoming much clearer now.