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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
