cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Ancona (JIRA)" <j...@apache.org>
Subject [jira] Created: (CASSANDRA-1680) Behavior of column value ByteBuffer returned from Thrift calls is surprising
Date Thu, 28 Oct 2010 22:28:20 GMT
Behavior of column value ByteBuffer returned from Thrift calls is surprising
----------------------------------------------------------------------------

                 Key: CASSANDRA-1680
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1680
             Project: Cassandra
          Issue Type: Bug
    Affects Versions: 0.7 beta 2
            Reporter: Jim Ancona


The Thrift Column object has a public ByteBuffer value member. In order to safely use that
member, you must first process it call TBaseHelper.rightSize(). The Thrift Column object does
this when getValue() is called, but of course has no way to do so when the value ByteBuffer
is accessed directly. The end result is that you get unexpected results when accessing the
ByteBuffer's underlying byte array. I suppose that arguably users of thrift should understand
ByteBuffer semantics well enough to avoid getting burned, but I think in practice this is
unlikely. 

You can reproduce the problem with the following sequence of operations in cassandra-cli in
the cassandra-0.7 branch:

[default@MyKeyspace] create column family CF1 with comparator=UTF8Type
76ab2284-e2e1-11df-93c0-e700f669bcfc
[default@MyKeyspace] set CF1[key][integer] = Integer(12345678987654321)
Value inserted.
[default@MyKeyspace] get CF1[key][integer]
=> (column=integer, value=12345678987654321, timestamp=1288304422843000)
[default@MyKeyspace] get CF1[key]         
=> (column=integer, value=-8104275257521291409654259134258589618690198366301968500366925384201062337700106679188936883799193604223363867889371831541230052432517523790062908835405316953744191265273683116032,
timestamp=1288304422843000)
Returned 1 results.

Note that the first Get returns the value that was set, but the second returns a bogus value
because it goes through a code path that uses the value ByteBuffer directly. I can supply
a patch for cassandra-cli, but I wonder if there's something that can be done at the Thrift
level to make it harder for this to occur.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message