Question on the symptoms of Ticket 260

scott clasen scott.clasen at
Wed Oct 13 20:07:37 EDT 2010


   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.  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

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

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

Is there anything I am missing, or any configuration or code that can
give me a consistent view?


More information about the riak-users mailing list