[openstack-dev] [oslo][messaging] 'retry' option
gsim at redhat.com
Fri Jun 27 16:05:08 UTC 2014
I do apologise for omitting the subject qualifiers in my previous mail!
On 06/27/2014 05:02 PM, Gordon Sim wrote:
> A question about the new 'retry' option. The doc says:
> By default, cast() and call() will block until the
> message is successfully sent.
> What does 'successfully sent' mean here? Does it mean 'written to the
> wire' or 'accepted by the broker'?
> For the impl_qpid.py driver, each send is synchronous, so it means
> accepted by the broker.
> What does the impl_rabbit.py driver do? Does it just mean 'written to
> the wire', or is it using RabbitMQ confirmations to get notified when
> the broker accepts it (standard 0-9-1 has no way of doing this).
> If the intention is to block until accepted by the broker that has
> obvious performance implications. On the other hand if it means block
> until written to the wire, what is the advantage of that? Was that a
> deliberate feature or perhaps just an accident of implementation?
> The use case for the new parameter, as described in the git commit,
> seems to be motivated by wanting to avoid the blocking when sending
> notifications. I can certainly understand that desire.
> However, notifications and casts feel like inherently asynchronous
> things to me, and perhaps having/needing the synchronous behaviour is
> the real issue? Calls by contrast, are inherently synchronous, but at
> present the retry controls only the sending of the request. If the
> server fails, the call may timeout regardless of the value of 'retry'.
> Just in passing, I'd suggest that renaming the new parameter
> max_reconnects, would make it's current behaviour and values clearer.
> The name 'retry' sounds like a yes/no type value, and retry=0 v. retry=1
> is the reverse of what I would intuitively expect.
>  I've personally considered that somewhat unnecessary.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev