[rabbitmq-discuss] Queuing for an application that does a fair amount of synchronous processing

[Matthias Radestock]

vishnu wrote:
> We're also looking at about 3000 messages/second (high side)
> [...]
> The way we plan to implement these synchronous messages is, similar to 
> the RPC model, to create a temporary queue when we send out a request 
> and subscribe to that queue with a timeout for a response, deleting it 
> after we're done.

Queue creation is quite expensive; creating a temporary queue for every 
single request is therefore quite costly and you may well not be able to 
get 3000Hz throughput that way.

Are you planning to create a connection per request too? That too would 
be costly.

I'd recommend using a pool of connections, with per-connection exclusive 
reply queues.

> now, if the webserver thread breaks out of the wait before the message 
> returns, my understanding is that the temporary queue gets deleted and 
> the response from the backend server is sent to the exchange where it 
> dies. (which is fine)
> 
> if the webserver thread breaks out of the wait after the message 
> returns, the queue gets deleted anyway and the message should vanish.
> 
> If the webserver thread dies for some reason, the queue gets auto 
> deleted and so the  backend server again sends the response to the 
> exchange to a non existent queue.
> 
> However, the problem comes in when the webserver thread dies just as the 
> response returns on the temporary queue. When this race condition 
> occurs, the queue should remain on the rabbitmq-server forever. Is this 
> right, or is there something I'm missing?

Exclusive queues get deleted when their creating connection disappears. 
So the answer to the above depends on how you manage the lifecycle of 
the AMQP connection.


Regards,

Matthias.