Re: Compaction Progress Greater than 100%

Looks like the same bug to me, whether it's caused by the same thing as it was originally doesn't really matter. Can you add your steps to reproduce it there? I'll reopen the bug for you. Thanks for the bug report! On Wed, Apr 2, 2014 at 11:43 PM, Ji Cheng wrote: > Hi, > > I found the compact

Compaction Progress Greater than 100%

Hi, I found the compaction progress is greater than 100%. I'm running 2.0.5. Not sure if it is a regression of CASSANDRA-4807 since we are performing size-tiered compaction in level 0 in 2.0. jicheng@S407:~$ /opt/cassandra/bin/nodetool -h 192.

Re: Replacing thrift calls in Hadoop input-split calculation with Java driver calls.

The Thrift IF predates vnodes. I agree that's a reasonable alternative. On Apr 2, 2014 12:47 PM, "Clint Kelly" wrote: > Hi all, > > FWIW the HBase Hadoop InputFormat does not even do this kind of estimation > of data density over various ranges; it just creates one split for every > region betwee

Re: Replacing thrift calls in Hadoop input-split calculation with Java driver calls.

Hi all, FWIW the HBase Hadoop InputFormat does not even do this kind of estimation of data density over various ranges; it just creates one split for every region between the start and stop keys of the scan. I'll probably just do something similar by combining token ranges for virtual nodes that