Timestamps have millisecond granularity. If you make multiple writes within the same millisecond, then the outcome is not deterministic.
Also, make sure you are running ntp. Clock skew will manifest itself similarly. On May 13, 2015, at 3:47 AM, Jared Rodriguez <jrodrig...@kitedesk.com<mailto:jrodrig...@kitedesk.com>> wrote: Thanks for the feedback. We have dug in deeper and upgraded to Cassandra 2.0.14 and are seeing the same issue. What appears to be happening is that if a record is initially written, then the first read is fine. But if we immediately update that record with a second write, that then the second read is problematic. We have a 4 node cluster and a replication factor of 2. What seems to be happening on the initial write the record is sent to nodes A and B. If a secondary write (update) of the record occurs while the record is in the memtable and not yet written to the sstable of A or B, that the next read returns nothing. We are continuing to dig in and get as much detail as possible before opening this as a JIRA. On Tue, May 12, 2015 at 6:51 PM, Robert Coli <rc...@eventbrite.com<mailto:rc...@eventbrite.com>> wrote: On Tue, May 12, 2015 at 12:35 PM, Michael Shuler <mich...@pbandjelly.org<mailto:mich...@pbandjelly.org>> wrote: This is a 4 node cluster running Cassandra 2.0.6 Can you reproduce the same issue on 2.0.14? (or better yet, the cassandra-2.0 branch HEAD, which will soon ship 2.0.15) If you get the same results, please, open a JIRA with the reproduction steps. And if you do file such a JIRA, please let the list know the JIRA URL, to close the loop! =Rob -- Jared Rodriguez
