|
|
| Author |
Message |
< RabbitMQ mailing list ~ Queuing for an application that does a fair amount of synchr |
| Guest |
 Posted: Thu Dec 31, 2009 3:16 pm |
 |
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Thu Dec 31, 2009 7:37 pm |
|
|
|
Guest
|
fair enough, let me come back with some numbers  , I just wanted to first make sure I'm not doing something brain dead . |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Jan 06, 2010 2:17 pm |
|
|
|
Guest
|
| We're also looking at about 3000 messages/second (high side), out of which we need 1000 of these to be persistent (since they represent payments that must happen). However all of these are currently meant to be synchronous, meaning we have someone sitting on a browser waiting for us to deal with this message and send a response back. So in the short term the only advantage we're hoping to gain is in the case of the persistent queues. In this case we're relying on the guarantee that the message will be dealt with even if there is some temporary glitch, and our web based client gets a timeout message. |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Jan 11, 2010 10:00 am |
|
|
|
Guest
|
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.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
