[
https://issues.apache.org/jira/browse/CASSANDRA-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867953#action_12867953
]
Toby Jungen commented on CASSANDRA-1093:
----------------------------------------
Yes, I'm flushing each node after the import. I've also tried flushing the
system keyspace (no effect). As noted in the readme, I would not be surprised
if this problem is unique to my hardware/software configuration and isn't an
inherent problem with Cassandra's BMT interface.
For what it's worth, I've hacked together a "workaround" for this problem by
writing SSTables directly (using o.a.c.io.SSTableWriter), copying the generated
files to appropriate directories on the nodes, and then restarting the nodes.
This solution is bound to result in other bugs, but for now I've verified that
there is no lost data with this method.
> BinaryMemtable interface silently dropping data.
> ------------------------------------------------
>
> Key: CASSANDRA-1093
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1093
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Linux Centos5, Fedora Core 4. Java HotSpot Server
> 1.6.0_14. See readme for more details.
> Reporter: Toby Jungen
> Fix For: 0.6.2
>
> Attachments: cassandra_bmt_test.tar.gz
>
>
> I've been attempting to use the Binary Memtable (BMT) interface to load a
> large number of rows. During my testing, I discovered that on larger loads
> (~1 million rows), occasionally some of the data never appears in the
> database. This happens in a non-deterministic manner, as sometimes all the
> data loads fine, and other times a significant chunk goes missing. No errors
> are ever logged to indicate a problem. I'm attaching some sample code that
> approximates my application's usage of Cassandra and explains this bug in
> more detail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
