[
https://issues.apache.org/jira/browse/CASSANDRA-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882351#action_12882351
]
Brandon Williams commented on CASSANDRA-1183:
---------------------------------------------
I modified Scott's code to pass explicit timestamps on writes and removes, and
used a local integer that I incremented after each use. Like this, I'm unable
to reproduce, so it appears the fault lies in the client's timestamp handling
somewhere.
> Column insert via batch_mutate under some conditions sometimes fails to add
> the column
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-1183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1183
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.6.1, 0.6.2
> Environment: OS (via uname -a): Linux 2.6.27.5-117.fc10.x86_64 #1
> SMP Tue Nov 18 11:58:53 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
> Java build 1.6.0_20-b02
> Cassandra 0.6.2 & 0.6.1
> hector-0.6.0-14.jar
> Reporter: Scott McCarty
> Assignee: Brandon Williams
> Attachments: BatchMutateBug.java
>
>
> Under heavy load batch_mutate sometimes fails to add a column but doesn't
> report an error to the client. Details:
> * client is running a tight loop that does: write to randomly named column;
> do a get_slice that should return that newly created column; delete the
> column if it was returned in get_slice
> * the mutation map for batch_insert has exactly one mutation in it: insert
> the column
> * if the column insert is done with the insert() API it doesn't ever fail
> (for as long as I've run it)
> * the column really isn't inserted as doing a 'get' on the entire rowkey in
> the command line interface doesn't show it, so it's not a timing issue
> * read consistency level is ONE, write consistency level is ALL
> * it fails on a single node cluster and on a 4 node cluster (replication
> factor = 3)
> I am attaching a Java cmdline program that demonstrates the problem; it uses
> the 'hector' java client (I hope that's okay--I verified that no errors or
> warning were being masked by hector).
> To show the failure using the program, just run it with the command line:
> bash> java BatchMutateBug localhost:9160 true keyspace columnfamily rowkey
> substituting in the appropriate Cassandra server connection info, a valid
> keyspace name, and a valid column family name. The second parameter ("true"
> in the example) tells the program to use batch_mutate(). If you pass in
> "false" it will use insert() and the program won't fail.
> I've tried the above on two different setups and each one fails within 10-15
> seconds generally. It seems to fail quickest if you use a non-existing
> rowkey.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
