cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Tolbert (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8555) Immediate sequential update of column sometimes not immediately applied (OS X only?)
Date Fri, 02 Jan 2015 20:45:34 GMT

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

Andy Tolbert updated CASSANDRA-8555:
------------------------------------
    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.  (was: OS X, Oracle JDK 1.7.0_71-b14, cassandra-2.0 HEAD, 1.2.19,
2.0.11, & 2.1.2.   1 node cluster.)

> 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)

Mime
View raw message