[ https://issues.apache.org/jira/browse/CASSANDRA-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264640#comment-14264640 ]
Andy Tolbert edited comment on CASSANDRA-8555 at 1/5/15 2:50 PM: ----------------------------------------------------------------- There is an explanation on the drivers user list here: https://groups.google.com/a/lists.datastax.com/forum/#!topic/java-driver-user/0IDCz96lAeA that explains what is going on well I think. The writes are given the same timestamp since they are done so closely together therefore the order of the mutations is not deterministic. The difference in behavior between cassandra-2.1 and 2.1.2 was strange to me though, but I do see that in some cases there is a 1 microsecond difference in timestamps, i.e.: 1420469181287000, 1420469181287001, where in the past i'd never see timestamps at microsecond precision (always ended with 000), maybe there was a change there? Resolving this as I think this is not an issue. was (Author: andrew.tolbert): There is an explanation on the drivers user list here: https://groups.google.com/a/lists.datastax.com/forum/#!topic/java-driver-user/0IDCz96lAeA that explains what is going on well I think. The writes are given the same timestamp since they are done so closely together therefore the order of the mutations is not deterministic. The difference in behavior between cassandra-2.1 and 2.1.2 was strange to me though, but I do see that in some cases there is a 1 microsecond difference in timestamps, i.e.: 1420469181287000, 1420469181287001, where in the past i'd never see timestamps at microsecond precision (always ended with 000), maybe there was a change there? > Immediate sequential update of column sometimes not immediately applied (OS X > only?) > ------------------------------------------------------------------------------------ > > Key: CASSANDRA-8555 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8555 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OS X 10.10.1, Oracle JDK 1.7.0_71-b14, cassandra-2.0 > HEAD, 1.2.19, 2.0.11, & 2.1.2. 1 node cluster. > Reporter: Andy Tolbert > Priority: Minor > > There was [a question on stack > overflow|http://stackoverflow.com/questions/27707081/cassandra-writes-after-setting-a-column-to-null-are-lost-randomly-is-this-a-bu] > from a user where they had a problem when doing the following: > {code:java} > @Test > public void testWriteUpdateRead() throws Exception { > Cluster cluster = Cluster.builder() > .addContactPoint("127.0.0.1") > .build(); > Session cs = cluster.connect(); > cs.execute("DROP KEYSPACE if exists readtest;"); > cs.execute("CREATE KEYSPACE readtest WITH replication " + > "= {'class':'SimpleStrategy', 'replication_factor':1};"); > cs.execute("create table readtest.sessions(" + > "id text primary key," + > "passwordHash text," + > ");"); > for (int i = 0; i < 1000; i++) { > String sessionID = UUID.randomUUID().toString(); > cs.execute("insert into readtest.sessions (id, passwordHash) values('" + > sessionID + "', null)"); > cs.execute("update readtest.sessions set passwordHash='" + sessionID + "' > where id = '" + sessionID + "' "); > ResultSet rs = cs.execute("select * from readtest.sessions where id = '" > + sessionID + "'"); > Row row = rs.one(); > assertThat("failed ith time=" + i, row.getString("passwordHash"), > equalTo(sessionID)); > } > cs.close(); > cluster.close(); > } > {code} > Running this test, there are times where the 'passwordHash' column was null, > making it seem like the update statement was never applied. > I can only reproduce this on OS X for some reason. I suspect this may be a > duplicate or was resolved coincidentally by a recent change, since it appears > to be resolved in the cassandra-2.1 and trunk branches, but I can reproduce > the issue against cassandra-2.1.2. The problem appears to still exist in > cassandra-2.0 HEAD. I went through CHANGES.txt for 2.1.3 and no fix stuck > out so I figured I'd create an issue just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)