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 su
The more I think about it, the more this feels like a column timestamp
issue. If two inserts have the same timestamp then the values are compared
lexically to decide which one to keep (which I think explains the
"99"/"100" "999"/"1000" mystery).
We can verify this by also selecting out the WRITETI
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
wrote:
> Hmm. I was able to reproduce the behavior with your go program on
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 s
Done: https://issues.apache.org/jira/browse/CASSANDRA-8892
On Mon, Mar 2, 2015 at 3:26 PM, Robert Coli wrote:
> On Mon, Mar 2, 2015 at 11:44 AM, Dan Kinder wrote:
>
>> I had been having the same problem as in those older post:
>> http://mail-archives.apache.org/mod_mbox/cassandra-user/201411.mb
On Mon, Mar 2, 2015 at 11:44 AM, Dan Kinder 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 thread :
"It soun
