It looks like NTP was the problem. Thanks for the solution!!! On Wed, May 13, 2015 at 9:20 AM, Robert Wille <rwi...@fold3.com> wrote:
> 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> > 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> wrote: > >> On Tue, May 12, 2015 at 12:35 PM, Michael Shuler <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 > > > -- Jared Rodriguez
