<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 7:45 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@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 09/18/2014 04:09 PM, Gordon Sim wrote:<br>
> On 09/18/2014 12:31 PM, Flavio Percoco wrote:<br>
>> On 09/17/2014 10:36 PM, Joe Gordon wrote:<br>
>>> My understanding of Zaqar is that it's like SQS. SQS uses distributed<br>
>>> queues, which have a few unusual properties [0]:<br>
>>><br>
>>><br>
>>>      Message Order<br>
>>><br>
>>> Amazon SQS makes a best effort to preserve order in messages, but due to<br>
>>> the distributed nature of the queue, we cannot guarantee you will<br>
>>> receive messages in the exact order you sent them. If your system<br>
>>> requires that order be preserved, we recommend you place sequencing<br>
>>> information in each message so you can reorder the messages upon<br>
>>> receipt.<br>
>>><br>
>><br>
>> Zaqar guarantees FIFO. To be more precise, it does that relying on the<br>
>> storage backend ability to do so as well. Depending on the storage used,<br>
>> guaranteeing FIFO may have some performance penalties.<br>
><br>
> Would it be accurate to say that at present Zaqar does not use<br>
> distributed queues, but holds all queue data in a storage mechanism of<br>
> some form which may internally distribute that data among servers but<br>
> provides Zaqar with a consistent data model of some form?<br>
<br>
</span>I think this is accurate. The queue's distribution depends on the<br>
storage ability to do so and deployers will be able to choose what<br>
storage works best for them based on this as well. I'm not sure how<br>
useful this separation is from a user perspective but I do see the<br>
relevance when it comes to implementation details and deployments.<br>
<span class=""><br>
<br>
> [...]<br>
>> As of now, Zaqar fully relies on the storage replication/clustering<br>
>> capabilities to provide data consistency, availability and fault<br>
>> tolerance.<br>
><br>
> Is the replication synchronous or asynchronous with respect to client<br>
> calls? E.g. will the response to a post of messages be returned only<br>
> once the replication of those messages is confirmed? Likewise when<br>
> deleting a message, is the response only returned when replicas of the<br>
> message are deleted?<br>
<br>
</span>It depends on the driver implementation and/or storage configuration.<br>
For example, in the mongodb driver, we use the default write concern<br>
called "acknowledged". This means that as soon as the message gets to<br>
the master node (note it's not written on disk yet nor replicated) zaqar<br>
will receive a confirmation and then send the response back to the<br>
client. This is also configurable by the deployer by changing the<br>
default write concern in the mongodb uri using `?w=SOME_WRITE_CONCERN`[0].<br></blockquote><div><br></div><div>This means that by default Zaqar cannot guarantee a message will be delivered at all. A message can be acknowledged and then the 'master node' crashes and the message is lost. Zaqar's ability to guarantee delivery is limited by the reliability of a single node, while something like swift can only loose a piece of data if 3 machines crash at the same time.</div><div> </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>
[0] <a href="http://docs.mongodb.org/manual/reference/connection-string/#uri.w" target="_blank">http://docs.mongodb.org/manual/reference/connection-string/#uri.w</a><br>
<span class=""><br>
><br>
>> However, as far as consuming messages is concerned, it can<br>
>> guarantee once-and-only-once and/or at-least-once delivery depending on<br>
>> the message pattern used to consume messages. Using pop or claims<br>
>> guarantees the former whereas streaming messages out of Zaqar guarantees<br>
>> the later.<br>
><br>
> From what I can see, pop provides unreliable delivery (i.e. its similar<br>
> to no-ack). If the delete call using pop fails while sending back the<br>
> response, the messages are removed but didn't get to the client.<br>
<br>
</span>Correct, pop works like no-ack. If you want to have pop+ack, it is<br>
possible to claim just 1 message and then delete it.<br>
<span class=""><br>
><br>
> What do you mean by 'streaming messages'?<br>
<br>
</span>I'm sorry, that went out wrong. I had the "browsability" term in my head<br>
and went with something even worse. By streaming messages I meant<br>
polling messages without claiming them. In other words, at-least-once is<br>
guaranteed by default, whereas once-and-only-once is guaranteed just if<br>
claims are used.<br>
<span class=""><br>
><br>
> [...]<br>
>> Based on our short conversation on IRC last night, I understand you're<br>
>> concerned that FIFO may result in performance issues. That's a valid<br>
>> concern and I think the right answer is that it depends on the storage.<br>
>> If the storage has a built-in FIFO guarantee then there's nothing Zaqar<br>
>> needs to do there. In the other hand, if the storage does not have a<br>
>> built-in support for FIFO, Zaqar will cover it in the driver<br>
>> implementation. In the mongodb driver, each message has a marker that is<br>
>> used to guarantee FIFO.<br>
><br>
> That marker is a sequence number of some kind that is used to provide<br>
> ordering to queries? Is it generated by the database itself?<br>
<br>
</span>It's a sequence number to provide ordering to queries, correct.<br>
Depending on the driver, it may be generated by Zaqar or the database.<br>
In mongodb's case it's generated by Zaqar[0].<br>
<br>
[0]<br>
<a href="https://github.com/openstack/zaqar/blob/master/zaqar/queues/storage/mongodb/queues.py#L103-L185" target="_blank">https://github.com/openstack/zaqar/blob/master/zaqar/queues/storage/mongodb/queues.py#L103-L185</a><br>
<span class=""><font color="#888888"><br>
--<br>
@flaper87<br>
Flavio Percoco<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>