<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 9:13 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 22/09/14 22:04, Joe Gordon wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
To me this is less about valid or invalid choices. The Zaqar team is<br>
comparing Zaqar to SQS, but after digging into the two of them, zaqar<br>
barely looks like SQS. Zaqar doesn't guarantee what IMHO is the most<br>
important parts of SQS: the message will be delivered and will never be<br>
lost by SQS.<br>
</blockquote>
<br></span>
I agree that this is the most important feature. Happily, Flavio has clarified this in his other thread[1]:<br>
<br>
*Zaqar's vision is to provide a cross-cloud interoperable,<br>
fully-reliable messaging service at scale that is both, easy and not<br>
invasive, for deployers and users.*<br>
<br>
...<br>
<br>
Zaqar aims to be a fully-reliable service, therefore messages should<br>
never be lost under any circumstances except for when the message's<br>
expiration time (ttl) is reached<br>
<br>
So Zaqar _will_ guarantee reliable delivery.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Zaqar doesn't have the same scaling properties as SQS.<br>
</blockquote>
<br></span>
This is true. (That's not to say it won't scale, but it doesn't scale in exactly the same way that SQS does because it has a different architecture.)<br>
<br>
It appears that the main reason for this is the ordering guarantee, which was introduced in response to feedback from users. So this is clearly a different design choice: SQS chose reliability plus effectively infinite scalability, while Zaqar chose reliability plus FIFO. It's not feasible to satisfy all three simultaneously, so the options are:<br>
<br>
1) Implement two separate modes and allow the user to decide<br>
2) Continue to choose FIFO over infinite scalability<br>
3) Drop FIFO and choose infinite scalability instead<br>
<br>
This is one of the key points on which we need to get buy-in from the community on selecting one of these as the long-term strategy.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Zaqar is aiming for low latency per message, SQS doesn't appear to be.<br>
</blockquote>
<br></span>
I've seen no evidence that Zaqar is actually aiming for that. There are waaay lower-latency ways to implement messaging if you don't care about durability (you wouldn't do store-and-forward, for a start). If you see a lot of talk about low latency, it's probably because for a long time people insisted on comparing Zaqar to RabbitMQ instead of SQS.<br></blockquote><div><br></div><div>I thought this was why Zaqar uses Falcon and not Pecan/WSME?</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:'Arial Unicode MS',Arial,sans-serif;font-size:14px;line-height:20px">"For an application like Marconi where throughput and latency is of paramount importance, I recommend Falcon over Pecan." </span><font color="#333333" face="Arial Unicode MS, Arial, sans-serif"><span style="font-size:14px;line-height:20px"><a href="https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation#Recommendation">https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation#Recommendation</a></span></font><br></div><div><font color="#333333" face="Arial Unicode MS, Arial, sans-serif"><br></font></div><div>Yes that statement mentions throughput as well, but it does mention latency as well.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
(Let's also be careful not to talk about high latency as if it were a virtue in itself; it's simply something we would happily trade off for other properties. Zaqar _is_ making that trade-off.)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So if Zaqar isn't SQS what is Zaqar and why should I use it?<br>
</blockquote>
<br></span>
If you are a small-to-medium user of an SQS-like service, Zaqar is like SQS but better because not only does it never lose your messages but they always arrive in order, and you have the option to fan them out to multiple subscribers. If you are a very large user along one particular dimension (I believe it's number of messages delivered from a single queue, but probably Gordon will correct me :D) then Zaqar may not _yet_ have a good story for you.<br>
<br>
cheers,<br>
Zane.<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/046809.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>September/046809.html</a><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>