cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6505) counters++ global shards 2.0 back port
Date Wed, 08 Jan 2014 20:36:51 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865863#comment-13865863
] 

Benedict commented on CASSANDRA-6505:
-------------------------------------

bq. I'd rather be on the safe side and save the allocations
I wouldn't worry about this particular duplicate() call. It will absolutely be stack allocated,
so won't affect the heap at all. ByteBufferUtil.arrayCopy devolves to a for loop of put/get
if either is a DirectByteBuffer (though this could be optimised) so it might also result in
suboptimal future behaviour, in a place we won't necessarily look to change.

> counters++ global shards 2.0 back port
> --------------------------------------
>
>                 Key: CASSANDRA-6505
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6505
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Aleksey Yeschenko
>            Assignee: Aleksey Yeschenko
>             Fix For: 2.0.5
>
>
> CASSANDRA-6504 introduces a new type of shard - 'global' - to 2.1. To enable live upgrade
from 2.0 to 2.1, it's necessary that 2.0 nodes are able to understand the new 'global' shards
in the counter contexts.
> 2.0 nodes will not produce 'global' shards, but must contain the merge logic.
> It isn't a trivial code change ("non-trivial code in a non-trivial part of the code"),
hence this separate JIRA issue.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message