Per Aleksey Yeschenko's comment on that ticket, it does seem like a
timestamp granularity issue, but it should work properly if it is within
the same session. gocql by default uses 2 connections and 128 streams per
connection. If you set it to 1 connection with 1 stream this problem goes
away. I
On Mon, Mar 2, 2015 at 11:44 AM, Dan Kinder dkin...@turnitin.com wrote:
I had been having the same problem as in those older post:
http://mail-archives.apache.org/mod_mbox/cassandra-user/201411.mbox/%3CCAORswtz+W4Eg2CoYdnEcYYxp9dARWsotaCkyvS5M7+Uo6HT1=a...@mail.gmail.com%3E
As I said on that
Yeah I thought that was suspicious too, it's mysterious and fairly
consistent. (By the way I had error checking but removed it for email
brevity, but thanks for verifying :) )
On Mon, Mar 2, 2015 at 4:13 PM, Peter Sanford psanf...@retailnext.net
wrote:
Hmm. I was able to reproduce the behavior
Hmm. I was able to reproduce the behavior with your go program on my dev
machine (C* 2.0.12). I was hoping it was going to just be an unchecked
error from the .Exec() or .Scan(), but that is not the case for me.
The fact that the issue seems to happen on loop iteration 10, 100 and 1000
is pretty
Done: https://issues.apache.org/jira/browse/CASSANDRA-8892
On Mon, Mar 2, 2015 at 3:26 PM, Robert Coli rc...@eventbrite.com wrote:
On Mon, Mar 2, 2015 at 11:44 AM, Dan Kinder dkin...@turnitin.com wrote:
I had been having the same problem as in those older post:
Hey all,
I had been having the same problem as in those older post:
http://mail-archives.apache.org/mod_mbox/cassandra-user/201411.mbox/%3CCAORswtz+W4Eg2CoYdnEcYYxp9dARWsotaCkyvS5M7+Uo6HT1=a...@mail.gmail.com%3E
To summarize it, on my local box with just one cassandra node I can update
and then
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
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 {
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
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
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
11 matches
Mail list logo
