[jira] [Resolved] (CASSANDRA-8555) Immediate sequential update of column sometimes not immediately applied (OS X only?)

["Andy Tolbert (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy Tolbert resolved CASSANDRA-8555.
-------------------------------------
       Resolution: Not a Problem
    Reproduced In: 2.1.2, 2.0.11, 1.2.19  (was: 1.2.19, 2.0.11, 2.1.2)

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)