Re: read after write inconsistent even on a one node cluster
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
Re: read after write inconsistent even on a one node cluster
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
Re: read after write inconsistent even on a one node cluster
On Thu, Nov 6, 2014 at 6:14 AM, Brian Tarbox briantar...@gmail.com wrote: 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? It sounds unreasonable/unexpected to me, if you have a trivial repro case, I would file a JIRA. =Rob
Re: read after write inconsistent even on a one node cluster
For cqlengine we do quite a bit of write then read to ensure data was written correctly, across 1.2, 2.0, and 2.1. For what it's worth, I've never seen this issue come up. On a single node, Cassandra only acks the write after it's been written into the memtable. So, you'd expect to see the most recent data. A possibility - if you're running in a VM, it's possible the clock isn't incrementing in real time? I've seen this happen with uuid1 generation - I was getting duplicates if I generated them fast enough. Perhaps you're writing 2 values one right after the other and they're getting the same millisecond precision timestamp. On Thu, Nov 6, 2014 at 10:26 AM, Robert Coli rc...@eventbrite.com wrote: On Thu, Nov 6, 2014 at 6:14 AM, Brian Tarbox briantar...@gmail.com wrote: 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? It sounds unreasonable/unexpected to me, if you have a trivial repro case, I would file a JIRA. =Rob -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
