[
https://issues.apache.org/jira/browse/CASSANDRA-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931574#comment-13931574
]
Sylvain Lebresne commented on CASSANDRA-6827:
---------------------------------------------
+1
> Using static with a counter column is broken
> --------------------------------------------
>
> Key: CASSANDRA-6827
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6827
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jeremiah Jordan
> Assignee: Aleksey Yeschenko
> Priority: Minor
> Fix For: 2.0.7
>
> Attachments: 6827.txt
>
>
> From a client:
> Looks like there is a problem with serialisation//deserialisation of static
> counters.
> It reproduces on the 2.0 branch, but doesn't appear to be a problem on trunk.
> Here is a small cql script which reproduces the problem:
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> use ks1;
> CREATE COLUMNFAMILY problematic ( stat_cnt counter static, norm_cnt counter,
> pk text, ck text, PRIMARY KEY (pk, ck) );
> UPDATE problematic SET stat_cnt = stat_cnt + 1 WHERE pk = 'foo';
> SELECT * FROM problematic ;
> and an example of the error from cqlsh:
> cqlsh:ks1> SELECT * FROM problematic ;
> pk | ck | stat_cnt | norm_cnt
> -----+------+--------------------------------------------------------------------------------------------------------------------------------------+----------
>
> foo | null |
> '\x00\x01\x00\x00\xf1$\t`\xa6\x1d\x11\xe3\x82\x9a\x9fqi\x80\x1f\xec\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01'
> | null
> (1 rows)
> Failed to decode value
> '\x00\x01\x00\x00\xf1$\t`\xa6\x1d\x11\xe3\x82\x9a\x9fqi\x80\x1f\xec\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01'
> (for column 'stat_cnt') as counter: unpack requires a string argument of
> length 8
> It seems like the problem lies in SelectStatement, it doesn't resolve the
> counter and ends up sending the entire 36 bytes of raw counter rather than
> the 8 bytes.
> In select statement we seem to keep the bytebuffer and then in two different
> places we end up calling the following method:
> Selection.ResultSetBuilder.add(ByteBuffer v )
> rather than: add(Column c)
> (Which in turn calls value() and invokes the CounterContext)
> I suppose the fix is just to ensure that the CounterContext is invoked for
> static counters.
> I can see various ways and places of putting it in place.
> Presumably you'd want to reconcile the static counters just once, earlier and
> keep the resolved value around to be ouput in several rows.
> I suppose somewhere here either by extending the ternary or changing
> getSimpleValue :
> staticValues.put(name, name.type.isCollection() ? getCollectionValue(name,
> group) : getSimpleValue(name, group));
> ColumnGroupMap seems to contain the relevant byte buffers and has methods:
> getCollection
> getSimple
> which could be extended to contain some counter related call wrapped in
> SelectStatement similarly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
