<div dir="ltr"><div>Thanks for sending this explanation, Vitaly! This helps for sure. Thank you all, guys!<br><br></div>-Qiang<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 6, 2016 at 3:24 AM, Vitaly E <span dir="ltr"><<a href="mailto:13vitamins@gmail.com" target="_blank">13vitamins@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p dir="ltr">Hi Qiang,</p>
<p dir="ltr">You mentioned that my suggestion to synchronize the clocks of your Riak nodes had solved the problem. Let me explain why -- it may clear things up for you.</p><p>Riak uses <a href="http://docs.basho.com/riak/latest/theory/concepts/context/#Vector-Clocks" target="_blank">vector clocks / version vectors</a> to keep track of the sequence of updates to a particular key. These are "logical clocks" as opposed to physical clocks that usually can't be relied upon in a distributed system like Riak. Fetching the vector clock of a key and passing it back on write (along with a new value), helps Riak decide which modification is the "latest" one. Keep in mind that "concurrent modification" does not necessary means simultaneous, but can happen due to a network partition, for example. <br></p><p>Normally, when a concurrent update is detected (based on vector clocks), Riak returns siblings and lets a client decide which version should be used. Since you're running with allow_mult = false, you've actually told Riak to resolve conflicts for you. In this case Riak still uses vector clocks when possible, and then time-stamps if there's still a conflict. Obviously, if you don't pass vector clocks, only time-stamps will be used. Moreover, without vector clocks any update is considered concurrent, Riak just doesn't expose it with allow_mult = false (remember, you opted for automatic conflict resolution?).<br></p><p>Keep in mind that a time-stamp is assigned by the first Riak node a request hits. The node then forwards the request based on <a href="http://docs.basho.com/riak/latest/theory/concepts/Clusters/" target="_blank">the key this request is trying to write</a>. <br></p><p>Now, imagine that a write to a key passes through node X, and within 30 sec another update to the same key passes through node Y, which is 2 min behind node X. Since time-stamps are being used to resolve conflicts, the second update will be considered older than the first one, and eventually discarded.</p><p>So, if this kind of conflict resolution is good enough for you, make sure your Riak's clocks are in sync (NTP?). I would also suggest to pass vector clocks anyway.<br></p><p></p>Hope this helps. Everyone is welcome to correct/clarify.<span class="HOEnZb"><font color="#888888"><br><br>Vitaly</font></span><div><div class="h5"><p dir="ltr"><br>
</p>
<div class="gmail_quote">On Mar 5, 2016 11:07 PM, "Qiang Cao" <<a href="mailto:caoqiang.cs@gmail.com" target="_blank">caoqiang.cs@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks, Russell. I'm just curious. My application handles that. Maybe that's just because of the vclock.<div><br></div><div>-Qiang<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 5, 2016 at 2:09 PM, Russell Brown <span dir="ltr"><<a href="mailto:russell.brown@me.com" target="_blank">russell.brown@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div>And you pass the vclock back after a GET with the next POST? Unless we get a look at the vclocks then it's hard to say why or where you have concurrency. But since concurrency is ultimately unavoidable using riak, why the concern? Can your application/data model handle it is the main question?<div><div><br><br>On 5 Mar 2016, at 19:04, Qiang Cao <<a href="mailto:caoqiang.cs@gmail.com" target="_blank">caoqiang.cs@gmail.com</a>> wrote:<br><br></div></div></div><div><div><div></div><blockquote type="cite"><div><div dir="ltr">Thanks, Russell! I do a GET immediately after a POST is done. I use apache httpclient, which handles requests synchronously. On the client, POSTs and GETs are sent out sequentially.<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 5, 2016 at 1:57 PM, Russell Brown <span dir="ltr"><<a href="mailto:russell.brown@me.com" target="_blank">russell.brown@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 5 Mar 2016, at 18:43, Qiang Cao <<a href="mailto:caoqiang.cs@gmail.com" target="_blank">caoqiang.cs@gmail.com</a>> wrote:<br>
<br>
> Just curious. The POSTs are sent out sequentially and a quorum is set up on Riak. I wonder how would it happen that Riak still considers the POST requests concurrent?<br>
</span>Did you read the result of POST 1 before sending POST 2? If not, and you don’t send the causal context, Riak has to view them as concurrent.<br>
<span><br></span></blockquote><div>How does the quorum work here?</div><div><br></div><div>Thanks,</div><div>Qiang</div></div></div></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span><br><span>riak-users mailing list</span><br><span><a href="mailto:riak-users@lists.basho.com" target="_blank">riak-users@lists.basho.com</a></span><br><span><a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" target="_blank">http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com</a></span><br></span></div></blockquote></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
riak-users mailing list<br>
<a href="mailto:riak-users@lists.basho.com" target="_blank">riak-users@lists.basho.com</a><br>
<a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" rel="noreferrer" target="_blank">http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com</a><br>
<br></blockquote></div>
</div></div></div>
</blockquote></div><br></div>