Elias, I'm not convinced that either the quorum or the number of nodes has any significance to the appearance of that problem. In order for the if_not_modified to work over PBC, the submitted vector clock must be equal to the one that Riak finds. As you say, the internal get for purposes of this comparison does not currently pass through any R/PR quorum parameters and so will use the bucket defaults.
So, it seems like the correct semantics would be to compare whether the partial orders of the vclocks relate, instead of being strictly equal. It would be probably be valid to continue the PUT if both replies from the internal get are older than the submitted vclock. Am I following your line of reasoning correctly? On Thu, Nov 8, 2012 at 11:19 AM, Elias Levy <fearsome.lucid...@gmail.com> wrote: > Sean, > > Thanks for the explanation. > > One last follow up. During testing I noticed that when using if_not_modified > against a test cluster with a node using the PB interface and the Ruby > client, if the bucket had an n_val greater than the number of nodes, the put > would fail with 'modified' error, even when you use a W, DW, and PW of 1. > > Presumably this is because the internal get performed by the if_not_modified > check within Riak uses the default R value, which is quorum, so if the > default n_val of 3 is used, it expect at least 2 replies, whereas there is > only one node available. Thus the get will fail. > > While a failure may be expected in this situation, the fact that is comes > back as a stale write error is confusing, as the data is not really stale. > > > On Thu, Nov 8, 2012 at 10:48 AM, Sean Cribbs <s...@basho.com> wrote: >> >> Elias, >> >> The resulting strategy of allow_mult=false and last_write_wins=false >> (which is a simplification for developer-friendliness mostly): >> >> 1) Resolve differences using the vector clock first. >> 2) If siblings still exist, return the one with the latest timestamp. >> >> So in a sense, it's a combination of vector-clock resolution and >> resolution by timestamp. This might be ok if your write rate is small, >> meaning that writes are unlikely to conflict; the upshot is that you >> don't have to worry about resolution. However, in general we suggest >> developers think about resolution strategies during development and >> then use allow_mult=true in production. > > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > -- Sean Cribbs <s...@basho.com> Software Engineer Basho Technologies, Inc. http://basho.com/ _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
