[rabbitmq-discuss] ConfirmSelect() overhead

[Adam Morgan]

Yeah, I was hoping to ensure guaranteed delivery simply, without caching messages for re-publishing, but looks like I'll have to add a thread and cache for doing this.

Is this the convention?  To cache the message with its sequence #, with another thread checking on the cache, attempting republish when Nacks received?

thx

On 5/30/13 2:23 PM, "Matthias Radestock" <matthias at rabbitmq.com> wrote:

Adam,

On 30/05/13 18:12, Adam Morgan wrote:
> Has anyone else done a test to determine the impact of enabling
> confirmSelect() on publishing channels with respect to publishing rates?
>   In preliminary testing I have seen slower throughput by a ratio of
> about 40:1.  Is this in line with what others have seen?

How are you using confirms?

If you are waiting for a confirm after every single publish then things
will go very slow indeed, since you are effectively making publish
synchronous, taking in the entire round trip and processing latency,
and, depending on the delivery mode, cost of writing to disk.

So don't do that. Ideally applications should handle confirms
asynchronously, decoupled from publishing. If that is too hard /
impractical, at least batch the waiting for confirms, e.g. wait for
confirms every n messages or n seconds.

Matthias.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130530/07eaf1da/attachment.htm>