On 09/22/2014 03:40 PM, Geoff O'Callaghan wrote:
That being said I'm not sure why a well constructed zaqar with an rpc
interface couldn't meet the requirements of oslo.messsaging and much more.
What Zaqar is today and what it might become may of course be different
things but as it stands today, Zaqar relies on polling which in my
opinion is not a natural fit for RPC. Though using an intermediary
for routing/addressing can be of benefit, store and forward is not
necessary and in my opinion even gets in the way.
Notifications on the other hand can benefit from store and forward and
may be less latency sensitive, alleviating the polling concerns.
One of the use cases I've heard cited for Zaqar is as an inbox for
recording certain sets of relevant events sent out by other open stack
services. In my opinion using oslo.messaging's notification API on the
openstack service side of this would seem - to me at least - quite
sensible, even if the events are then stored in (or forwarded to) Zaqar
and accessed by users through Zaqar's own protocol.
 The latency of an RPC call as perceived by the client is going to
depend heavily on the polling frequency; to get lower latency, you'll
need to pool more frequently both on the server and on the client.
However polling more frequently results in increased load even when no
requests are being made.
 I am of the view that reliable RPC is best handled by replaying the
request from the client when needed, rather than trying to make the
request and reply messages durably recorded, replicated and reliably
delivered. Doing so is more scalable and simpler. An end-to-end
acknowledgement for the request (rather than a broker taking
responsibility and acknowledging the request independent of delivery
status) makes it easier to detect failures and trigger a resend.
OpenStack-dev mailing list