On Mon, Jun 28, 2010 at 02:29, Todd Nine <t...@spidertracks.co.nz> wrote:
> Hi all,
>  I thought the dev list would be more appropriate for this discussion.  I'm
> having issues inserting Numeric Range keys in Lucandra and I've determined
> the issue (I think).  Numeric keys are encoded with a trie data structure.
> The bits of the underlying values are packed 7 bits at a time into a UTF-8
> character.  Bits are then shifted from the right LSB, and the number of bits
> shifted is put as the first byte.  This gives an array of bytes with the
> characters actually containing bit values of the underlying long data type.
>  Here is the source that performs the shift operations.
>
> http://svn.apache.org/viewvc/lucene/java/tags/lucene_3_0_2/src/java/org/apache/lucene/util/NumericUtils.java?revision=955593&view=markup
>
> I've created a JIRA issue with a test case that displays the error.  I have
> a test that demonstrates the input in both direct write mode and
> batch_mutation.  I can only reproduce the bytes getting dropped via the
> batch mutation operations.  My second test that performs direct writes
> correctly writes and retrieves the values.
>
> http://issues.apache.org/jira/browse/CASSANDRA-1235
>
>
> Where would I begin looking at the fix for this? Its unfortunately killing
> our productivity, and doing single write inserts as a workaround is woefully
> inefficient for the amount of data we need to write.

o.a.c.t.CassandraServer.batch_mutate().  Check first to make sure your
thrift Mutations are being turned into RowMutations correctly.  If
that checks out fine, then you need to debug it in
StorageProxy.mutateBlocking().  Lots of other calls (regular inserts)
use mutateBlocking(), so chances are that whatever badness is
happening in during the Mutation->RowMutation conversion.

Gary.

>
> Thanks,
> Todd
>

Reply via email to