RabbitMQ creates a temporary queue but don't know how or when

Question

I'm using Mule ESB with two apps (one publishes status to the other through rabbitMQ). ONLY in my production environment, I get these amqp.gen- queues popping up but they're locked and I can't see what's inside of them. They're bound to my exchange (the publisher).

Customer is pointing at it as the problem for random assets being lost. I'm trying to eliminate them from happening but haven't got a clue. According to the rabbitMQ tutorial, these are created when you declare a queue but don't provide a name. However, I'm not doing that.

More info: The two apps use different logins to rabbitMQ and the queues are created by my app (the publisher), not the consumer app. I don't have a queue name and my queue declaration looks like this:

<amqp:connector name="amqpConnector"
    host="${myApp.status_reporting.host}"
    port="${myApp.status_reporting.port}"
    username="${myApp.status_reporting.username}"
    password="${myApp.status_reporting.password}"
    requestedHeartbeat="${myApp.status_reporting.requestedHeartbeat}"
    doc:name="AMQP Connector for Status Messages"/>


<flow name="cwm_send" doc:name="cwm_send">
    <amqp:outbound-endpoint 
        exchangeName="${myApp.status_reporting.exchange_name}"
        exchangeType="topic"
        exchangeDurable="${myApp.status_reporting.exchange_is_durable}"
        routingKey="${myApp.status_reporting.routing_key}"
        connector-ref="amqpConnector" 
        doc:name="AMQP Out" 
        queueDurable="true" 
        responseTimeout="10000"
    />
</flow>

As you can see, there's no queue name. just a routing key.

My question is this: If there's no queue's bound to this exchange that match this routing key, is this why these temporary queues getting created? How can my app retrieve the messages that are locked in them? Am I doing something wrong architecturally?

Sorry for the open ended questions, but I gotta start somewhere.

Answer 1

The outbound-endpoint has no exchange-pattern configured. IIRC it defaults to request-response.

Given that there is no REPLY_TO header, the endpoint decides to create a temporary queue, send the message to the exchange and subscribe for an answer in the temporary queue.

If you don't want this behaviour just add exchange-pattern="one-way" to the outbound endpoint.