Question on the symptoms of Ticket 260

Scott Clasen scott.clasen at gmail.com
Thu Oct 14 10:11:30 EDT 2010


Hi Dan-

It is a single client, with no other clients connected to riak.

It is really deletes that seem to be missed/lagging, and deletes don't take a vector clock?

Pseudocode is something like this...all keys and values are raw bytes wrapped in protobuf bytestring

Store(bucket,key,value)
Store(bucket,key2,key)
Fetch(bucket,key) // properly returns value
Delete(bucket,key)
Delete(bucket,key2)
Fetch(bucket,key) //properly returns null
Store(bucket,key,value)
Store(bucket,key2,key)
Fetch(bucket,key) // properly returns value
Delete(bucket,key)
Delete(bucket,key2)
Fetch(bucket,key) // !!!incorrectly returns value instead of null

The correct value is returned if I have breakpoints set that effectively give some wait time between the last delete and fetch.


I will code up a simplified test case tonight, maybe it will reveal an error on my side.

Thanks
Sent from my iPhone

On Oct 13, 2010, at 9:21 PM, Dan Reverri <dan at basho.com> wrote:

> Hi SC,
> 
> If a single client is writing to a single key with read and write quorums your reads should reflect your writes. Are other clients updating the same key concurrently? Are you updating the values with the correct vclock? Would it be possible to provide a minimal test case that reproduces the issue?
> 
> Thanks,
> Dan
> 
> Daniel Reverri
> Developer Advocate
> Basho Technologies, Inc.
> dan at basho.com
> 
> 
> On Wed, Oct 13, 2010 at 5:07 PM, scott clasen <scott.clasen at gmail.com> wrote:
> Hi-
> 
>    I am writing a Riak backend for Akka's persistent data structures,
> and am running into what looks like behavior similar to what is
> mentioned in this ticket.
> 
> https://issues.basho.com/show_bug.cgi?id=260  which says--->
> 
> In cases where objects are rapidly updated and deleted, unpredictable behavior
> seems to occur due to race conditions.  Exposing tombstones to the client when
> allow_mult is true would allow resolution of the conflict that is normally
> hidden from the user. This will require the client who is interested in
> resolving delete+update conflicts to submit the vclock when performing the
> delete.
> 
> This is on a single riak instance 0.13.0, on OS X, installed via 'brew
> install riak', w
> 
> The behavior I am seeing is in a single threaded test that rapidly
> inserts, updates and deletes the value for a single key in a single
> bucket.
> 
> This is using the protobuf interface, via the riak-java-pb-client.
> All reads use quorum, and all writes use quorum and durableWrite
> quorum as well.
> 
> Running the tests outside the debugger cause test failures because the
> reads are not seeing the latest write/delete
> 
> When I run the tests in debug mode, with breakpoints set to watch the
> values returned from riak, the tests pass.
> 
> This makes me think there is some race condition like the one
> mentioned in ticket 260 occurring. Although it could certainly be user
> error  ;).
> 
> Other than the default config, I have tried fiddling with
> last_write_wins and allow_multi but no combination of those seem to
> help.
> 
> Is there anything I am missing, or any configuration or code that can
> give me a consistent view?
> 
> Thanks
> SC
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20101014/863f2cfd/attachment.html>


More information about the riak-users mailing list