[
https://issues.apache.org/jira/browse/CASSANDRA-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13866559#comment-13866559
]
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: 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)
