Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sat, 8 Mar 2014 04:36:43 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12699561.1394241347472.28706.1394253403205@arcas>
In-Reply-To: <JIRA.12699561.1394241347472@arcas>
References: <JIRA.12699561.1394241347472@arcas>
Subject: [jira] [Updated] (CASSANDRA-6827) Using static with a counter
 column is broken
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko updated CASSANDRA-6827:
-----------------------------------------

    Priority: Minor  (was: Major)

> 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: Sylvain Lebresne
>            Priority: Minor
>
> 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)