Question on the symptoms of Ticket 260

scott clasen scott.clasen at
Thu Oct 14 19:04:33 EDT 2010

Hi Dan-

Here is a test case, strangely it passes the first time that is run
then fails all subsequent runs....running it would require
scala,scalatest,the riak-java-pb-client and the protobuf jars.

My guess is that it is vector clock related at this point, but looking
through the code to the riak-java-pb-client, there is no way to set
the vector clock when creating a new RiakObject or set a new value on
a RiakObject retrieved from the server.

import com.trifork.riak.{RiakClient, RequestMeta, RiakObject}
import org.scalatest.matchers.ShouldMatchers
import org.scalatest.Spec

class RiakConsistencyTest extends Spec with ShouldMatchers {
  describe("the consistency issue I see") {
    it("is demonstrated by the failure of the following tests") {
      val riakClient = new RiakClient("localhost");
      val maps = copyFromUtf8("Maps")
      val key = copyFromUtf8("key");
      val otherkey = copyFromUtf8("otherkey")
      val value = copyFromUtf8("value")
      val x = copyFromUtf8("x")
      val quorum = 0xfffffffd
      val meta = new RequestMeta().w(quorum).dw(quorum) RiakObject(maps, key, otherkey), meta) RiakObject(maps, otherkey, value), meta)
      riakClient.fetch(maps, key, quorum)(0).getValue.toStringUtf8
should be (otherkey.toStringUtf8)
      riakClient.fetch(maps, otherkey)(0).getValue.toStringUtf8 should
      riakClient.delete(maps, otherkey) RiakObject(maps, key, x), meta)
      riakClient.fetch(maps, otherkey, quorum).size should be(0)
      riakClient.fetch(maps, key, quorum)(0).getValue.toStringUtf8
should be (x.toStringUtf8)  //Fails here


"otherkey" was not equal to "x"
org.scalatest.TestFailedException: "otherkey" was not equal to "x"
	at org.scalatest.matchers.Matchers$class.newTestFailedException(Matchers.scala:148)
	at RiakConsistencyTest.newTestFailedException(RiakConsistencyTest.scala:6)
	at org.scalatest.matchers.ShouldMatchers$ShouldMethodHelper$.shouldMatcher(ShouldMatchers.scala:871)
	at org.scalatest.matchers.ShouldMatchers$StringShouldWrapper.should(ShouldMatchers.scala:1081)
	at RiakConsistencyTest$$anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(RiakConsistencyTest.scala:25)
	at RiakConsistencyTest$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(RiakConsistencyTest.scala:8)
	at RiakConsistencyTest$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(RiakConsistencyTest.scala:8)
	at org.scalatest.Spec$$anon$2.apply(Spec.scala:1388)

On Thu, Oct 14, 2010 at 10:11 AM, Scott Clasen <scott.clasen at> wrote:
> 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> 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
> On Wed, Oct 13, 2010 at 5:07 PM, scott clasen <scott.clasen at>
> 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.
>>  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

More information about the riak-users mailing list