Open Stack

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[1].
>
> 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.
>
> --Gordon.
>
> [1] I've personally considered that somewhat unnecessary.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>