Hi, I'm seeing a problem with inserting columns into one key using multiple threads and I'm not sure if it's a bug or if it's my misunderstanding of how insert/get_slice should work.
My setup is that I have two separate client processes, each with a single thread, writing concurrently to Cassandra and each process is doing the same thing: read columns from one key and then use one of the column names as the basis for another row key, and then insert into that new row key a column whose name is unique to the process. Each process then immediately reads back the columns on that row key. It's the reading back part that's showing inconsistent behavior: most of the time if Thread1 writes Column1 and Thread2 writes Column2 at about the same time, things are consistent: Thread1 sees either Column1 or it sees Column1 and Column 2 (same for Thread2). Both of those cases are expected and indeed comprise 99% of the results. Sometimes, however, Thread1 sees NO columns, and sometimes it sees Column2 (instead of Column1, as I'd expect). Debug logs show that in failing cases, Thread1 completes its insert/get_slice sequence BEFORE Thread2 starts its insert/get_slice, but (in this example) Thread2 would get back NO columns. I turned on debug level of logging on Cassandra and I saw that in at least one case the two client requests are coming in at the exact same millisecond so I'm wondering if there's some concurrency issue on the server. I'm running linux with Java build 1.6.0_20-b02. Cassandra is version 0.6.1 and I have one node in the cluster. The consistency level for writing is ALL and for reading it's ONE. The clients are using the Java Hector interface. Both of the two client processes are on the same machine as the Cassandra server (running on a dual-core processor). This fails with 0.6.2 code also. Am I wrong in thinking that an insert on a column with consistency level ALL followed immediately by a get_slice should include that column? Thanks Scott McCarty
