cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6505) counters++ global shards 2.0 back port
Date Thu, 09 Jan 2014 11:17:53 GMT


Sylvain Lebresne commented on CASSANDRA-6505:

bq. I wouldn't worry about this particular duplicate() call

And I'm sure you're right, really. Yet, I'd still rather not having it. I could tell you that
that it's because in that very specific case I'm truly concerned about this backport breaking
someone (anyone) and so I'd rather not rely on low level optimization of the JVM when it's
so trivial not to, though in reality, this may have more to do with my inherent stubbornness.

bq.  so it might also result in suboptimal future behaviour

That, I don't give a crap, mainly because we know that this code will go away with CASSANDRA-6504.

Don't get me wrong, I'd 100% agree with you in almost any other ticket. I don't like this
ticket. We must do it, I'm convinced of that, but it worries me. Hence I'd rather be over
cautious, even if it's not entirely justified, that not enough. But anyway, just my 2 cents.

> counters++ global shards 2.0 back port
> --------------------------------------
>                 Key: CASSANDRA-6505
>                 URL:
>             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

View raw message