Thanks. Right now its just for testing but in general we can't guard
against multiple users ending up the one writes and then one reads.
It would be one thing if the read just got old data but we're seeing it
return wrong data...i.e. data that doesn't correspond to any particular
version of the object.
Brian
On Thu, Nov 6, 2014 at 10:30 AM, Eric Stevens <migh...@gmail.com> wrote:
> If this is just for doing tests to make sure you get back the data you
> expect, I would recommend looking some sort of eventually construct in your
> testing. We use Specs2 as our testing framework, and our write-then-read
> tests look something like this:
>
> someDAO.write(someObject)
>
> eventually {
> someDAO.read(someObject.id) mustEqual someObject
> }
>
> This will retry the read repeatedly over a short duration.
>
> Just in case you are trying to do write-then-read outside of tests, you
> should be aware that it's a Bad Idea™, but your email reads like you
> already know that =)
>
> On Thu Nov 06 2014 at 7:16:25 AM Brian Tarbox <briantar...@gmail.com>
> wrote:
>
>> We're doing development on a single node cluster (and yes of course we're
>> not really deploying that way), and we're getting inconsistent behavior on
>> reads after writes.
>>
>> We write values to our keyspaces and then immediately read the values
>> back (in our Cucumber tests). About 20% of the time we get the old
>> value.....if we wait 1 second and redo the query (within the same java
>> method) we get the new value.
>>
>> This is all happening on a single node...how is this possible?
>>
>> We're using 2.0.9 and the java client. Though it shouldn't matter given
>> a single node cluster I set the consistency level to ALL with no effect.
>>
>> I've read CASSANDRA-876 which seems spot-on but it was closed as
>> won't-fix...and I don't see what the solution is.
>>
>> Thanks in advance for any help.
>>
>> Brian Tarbox
>>
>> --
>> http://about.me/BrianTarbox
>>
>
--
http://about.me/BrianTarbox
