[jira] [Created] (CASSANDRA-14559) Check for endpoint collision with hibernating nodes
Vincent White created CASSANDRA-14559: - Summary: Check for endpoint collision with hibernating nodes Key: CASSANDRA-14559 URL: https://issues.apache.org/jira/browse/CASSANDRA-14559 Project: Cassandra Issue Type: Bug Reporter: Vincent White I ran across an edge case when replacing a node with the same address. This issue results in the node(and its tokens) being unsafely removed from gossip. Steps to replicate: 1. Create 3 node cluster. 2. Stop a node 3. Replace the stopped node with a node using the same address using the replace_address flag 4. Stop the node before it finishes bootstrapping 5. Remove the replace_address flag and restart the node to resume bootstrapping (if the data dir is also cleared at this point the node will also generate new tokens when it starts) 6. Stop the node before it finishes bootstrapping again 7. 30 Seconds later the node will be removed from gossip because it now matches the check for a FatClient I think this is only an issue when replacing a node with the same address because other replacements now use STATUS_BOOTSTRAPPING_REPLACE and leave the dead node unchanged. I believe the simplest fix for this is to add a check that prevents a non-bootstrapped node (without the replaces_address flag) starting if there is a gossip entry for the same address in the hibernate state. [3.11 PoC |https://github.com/apache/cassandra/compare/trunk...vincewhite:check_for_hibernate_on_start] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14393) Incorrect view updates
[
https://issues.apache.org/jira/browse/CASSANDRA-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534396#comment-16534396
]
ZhaoYang commented on CASSANDRA-14393:
--
Perhaps we should just force users to include all base columns.
> Incorrect view updates
> --
>
> Key: CASSANDRA-14393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14393
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
>Reporter: Duarte Nunes
>Priority: Major
> Labels: materializedviews
>
> Consider the following:
> {noformat}
> create table t (p int, c int, v1 int, v2 int, primary key(p, c));
> create materialized view mv as select p, c, v1 from t
> where p is not null and c is not null primary key (c, p);
> insert into t (p, c, v1, v2) VALUES(1, 1, 1, 1) using ttl 5;
> update t using ttl 1000 set v2 = 1 where p = 1 and c = 1;
> delete v2 from t where p = 1 and c = 1;
> // Wait 5 seconds
> select * from mv;
> c | p | v1
> ---+---+--
> 1 | 1 | null{noformat}
> The view row should be dead after 5 seconds, but it is not.
> This is because the liveness info calculated when deleting v2 is based on the
> base table update liveness info, which has the timestamp of the first insert
> statement. That liveness info is shadowed by the liveness info created in the
> update, which has a higher timestamp.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534387#comment-16534387 ] Nancy Schorr commented on CASSANDRA-13047: -- Thanks Patrick. How about a redirect for "https://cassandra.apache.org/doc/cql3/CQL-3.2.html"; to some kind of explanation or advice. At this point - all help in cqlsh is unavailable to the user. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534374#comment-16534374 ] Patrick Bannister commented on CASSANDRA-13047: --- [~nmschorr], yes, it sounds like you're experiencing the bug addressed by this ticket. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534348#comment-16534348 ] Nancy Schorr edited comment on CASSANDRA-13047 at 7/6/18 1:09 AM: -- Is this bug related to the problem of typing "help date" or help which sends the user to a non-existent webpage? For instance, in cqlsh type "help time" and the browser is opened and attempts to go to "https://cassandra.apache.org/doc/cql3/CQL-3.2.html#usingtime"; which doesn't exist. The page says: "Not Found The requested URL /doc/cql3/CQL-3.2.html was not found on this server." I'm using 3.11.2 on Centos. Seems like the root cause is the same as this bug, so I don't want to clutter the system in case it is as I'm new to this project. h1. was (Author: nmschorr): Is this bug related to the problem of typing "help date" or help sends the user to a non-existent webpage? For instance, in csqsh type "help time" and the browser is opened and attempts to go to "https://cassandra.apache.org/doc/cql3/CQL-3.2.html#usingtime"; which doesn't exist. The page says: "Not Found The requested URL /doc/cql3/CQL-3.2.html was not found on this server." I'm using 3.11.2 on Centos. Seems like the root cause is the same as this bug, so I don't want to clutter the system in case it as as I'm new to this project. h1. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534348#comment-16534348 ] Nancy Schorr commented on CASSANDRA-13047: -- Is this bug related to the problem of typing "help date" or help sends the user to a non-existent webpage? For instance, in csqsh type "help time" and the browser is opened and attempts to go to "https://cassandra.apache.org/doc/cql3/CQL-3.2.html#usingtime"; which doesn't exist. The page says: "Not Found The requested URL /doc/cql3/CQL-3.2.html was not found on this server." I'm using 3.11.2 on Centos. Seems like the root cause is the same as this bug, so I don't want to clutter the system in case it as as I'm new to this project. h1. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14555) Verify effect of CASSANDRA-14252 on streaming endpoint selection
[
https://issues.apache.org/jira/browse/CASSANDRA-14555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534153#comment-16534153
]
Dikang Gu commented on CASSANDRA-14555:
---
Thanks [~jay.zhuang] !
> Verify effect of CASSANDRA-14252 on streaming endpoint selection
>
>
> Key: CASSANDRA-14555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14555
> Project: Cassandra
> Issue Type: Task
> Components: Streaming and Messaging
>Reporter: Sam Tunnicliffe
>Priority: Major
> Fix For: 4.x
>
>
> CASSANDRA-14252 makes a slight change to {{DynamicEndpointSnitch}} so that it
> is somewhat more likely a replica in a remote DC is contacted when replicas
> in the local DC are considered degraded. This seems reasonable on the read
> path, but it could also affect selection of endpoints for streaming and cross
> DC streaming is probably something that operators want to control more
> tightly. To be clear, I’m not 100% sure that this is actually an issue, but
> I’d like to have some investigation into it before we ship a change to
> default behaviour.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[ https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534146#comment-16534146 ] Benedict commented on CASSANDRA-7282: - Thanks. I'm surprised, and will dig into this a little more myself. However, we have to be careful with these microbenchmarks. The whole state fits in L1 cache here, but there's a good chance this will not be hot in L1 in live operation, given how poor our general cache usage is; it's certainly less likely with the tree approach (given it is much larger in memory). So if the scores are similar (which they are), I would still prefer the array variant. Still, it should be outright faster, so I'll take a look and see if I can figure out why you're seeing this behaviour. > Faster Memtable map > --- > > Key: CASSANDRA-7282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7282 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Michael Burman >Priority: Major > Labels: performance > Fix For: 4.x > > Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg, > run1.svg, writes.svg > > > Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in > our memtables. Maintaining this is an O(lg(n)) operation; since the vast > majority of users use a hash partitioner, it occurs to me we could maintain a > hybrid ordered list / hash map. The list would impose the normal order on the > collection, but a hash index would live alongside as part of the same data > structure, simply mapping into the list and permitting O(1) lookups and > inserts. > I've chosen to implement this initial version as a linked-list node per item, > but we can optimise this in future by storing fatter nodes that permit a > cache-line's worth of hashes to be checked at once, further reducing the > constant factor costs for lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[ https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534129#comment-16534129 ] Michael Burman commented on CASSANDRA-7282: --- I updated the original gist > Faster Memtable map > --- > > Key: CASSANDRA-7282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7282 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Michael Burman >Priority: Major > Labels: performance > Fix For: 4.x > > Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg, > run1.svg, writes.svg > > > Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in > our memtables. Maintaining this is an O(lg(n)) operation; since the vast > majority of users use a hash partitioner, it occurs to me we could maintain a > hybrid ordered list / hash map. The list would impose the normal order on the > collection, but a hash index would live alongside as part of the same data > structure, simply mapping into the list and permitting O(1) lookups and > inserts. > I've chosen to implement this initial version as a linked-list node per item, > but we can optimise this in future by storing fatter nodes that permit a > cache-line's worth of hashes to be checked at once, further reducing the > constant factor costs for lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-7282) Faster Memtable map
[
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534123#comment-16534123
]
Michael Burman edited comment on CASSANDRA-7282 at 7/5/18 8:45 PM:
---
Updated the code with hopefully what you meant.. (need to get some sleep). I
see worse performance, which I believe is because the added complexity of the
minimum processing (the improved memory layout does not help enough - maybe the
microbenchmark fits the caches in other cases also). I'll need to investigate
more tomorrow.
{code}
[java] Benchmark(vnodes) Mode Cnt Score
Error Units
[java] BSTBench.multiArrayBinarySeek 4 thrpt 16 106134.448 ±
3211.072 ops/ms
[java] BSTBench.multiArrayBinarySeek 16 thrpt 16 21704.218 ±
788.881 ops/ms
[java] BSTBench.multiArrayBinarySeek 64 thrpt 164347.090 ±
106.703 ops/ms
[java] BSTBench.multiArrayBinarySeek 256 thrpt 16 667.122 ±
210.476 ops/ms
[java] BSTBench.multiArrayBinarySeek 512 thrpt 16 192.777 ±
29.690 ops/ms
[java] BSTBench.multiArrayLinearSearch 4 thrpt 16 172888.358 ±
7778.132 ops/ms
[java] BSTBench.multiArrayLinearSearch16 thrpt 16 16703.622 ±
565.180 ops/ms
[java] BSTBench.multiArrayLinearSearch64 thrpt 161096.093 ±
33.050 ops/ms
[java] BSTBench.multiArrayLinearSearch 256 thrpt 16 84.511 ±
2.776 ops/ms
[java] BSTBench.multiArrayLinearSearch 512 thrpt 16 22.130 ±
0.714 ops/ms
{code}
was (Author: burmanm):
Updated the code with hopefully what you meant.. (need to get some sleep). I
see worse performance, which I believe is because the added complexity of the
minimum processing. I'll need to investigate more tomorrow.
{code}
[java] Benchmark(vnodes) Mode Cnt Score
Error Units
[java] BSTBench.multiArrayBinarySeek 4 thrpt 16 106134.448 ±
3211.072 ops/ms
[java] BSTBench.multiArrayBinarySeek 16 thrpt 16 21704.218 ±
788.881 ops/ms
[java] BSTBench.multiArrayBinarySeek 64 thrpt 164347.090 ±
106.703 ops/ms
[java] BSTBench.multiArrayBinarySeek 256 thrpt 16 667.122 ±
210.476 ops/ms
[java] BSTBench.multiArrayBinarySeek 512 thrpt 16 192.777 ±
29.690 ops/ms
[java] BSTBench.multiArrayLinearSearch 4 thrpt 16 172888.358 ±
7778.132 ops/ms
[java] BSTBench.multiArrayLinearSearch16 thrpt 16 16703.622 ±
565.180 ops/ms
[java] BSTBench.multiArrayLinearSearch64 thrpt 161096.093 ±
33.050 ops/ms
[java] BSTBench.multiArrayLinearSearch 256 thrpt 16 84.511 ±
2.776 ops/ms
[java] BSTBench.multiArrayLinearSearch 512 thrpt 16 22.130 ±
0.714 ops/ms
{code}
> Faster Memtable map
> ---
>
> Key: CASSANDRA-7282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benedict
>Assignee: Michael Burman
>Priority: Major
> Labels: performance
> Fix For: 4.x
>
> Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg,
> run1.svg, writes.svg
>
>
> Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in
> our memtables. Maintaining this is an O(lg(n)) operation; since the vast
> majority of users use a hash partitioner, it occurs to me we could maintain a
> hybrid ordered list / hash map. The list would impose the normal order on the
> collection, but a hash index would live alongside as part of the same data
> structure, simply mapping into the list and permitting O(1) lookups and
> inserts.
> I've chosen to implement this initial version as a linked-list node per item,
> but we can optimise this in future by storing fatter nodes that permit a
> cache-line's worth of hashes to be checked at once, further reducing the
> constant factor costs for lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[ https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534127#comment-16534127 ] Benedict commented on CASSANDRA-7282: - Do you want to post a link to the code before hitting the sack? > Faster Memtable map > --- > > Key: CASSANDRA-7282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7282 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Michael Burman >Priority: Major > Labels: performance > Fix For: 4.x > > Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg, > run1.svg, writes.svg > > > Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in > our memtables. Maintaining this is an O(lg(n)) operation; since the vast > majority of users use a hash partitioner, it occurs to me we could maintain a > hybrid ordered list / hash map. The list would impose the normal order on the > collection, but a hash index would live alongside as part of the same data > structure, simply mapping into the list and permitting O(1) lookups and > inserts. > I've chosen to implement this initial version as a linked-list node per item, > but we can optimise this in future by storing fatter nodes that permit a > cache-line's worth of hashes to be checked at once, further reducing the > constant factor costs for lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534123#comment-16534123
]
Michael Burman commented on CASSANDRA-7282:
---
Updated the code with hopefully what you meant.. (need to get some sleep). I
see worse performance, which I believe is because the added complexity of the
minimum processing. I'll need to investigate more tomorrow.
{code}
[java] Benchmark(vnodes) Mode Cnt Score
Error Units
[java] BSTBench.multiArrayBinarySeek 4 thrpt 16 106134.448 ±
3211.072 ops/ms
[java] BSTBench.multiArrayBinarySeek 16 thrpt 16 21704.218 ±
788.881 ops/ms
[java] BSTBench.multiArrayBinarySeek 64 thrpt 164347.090 ±
106.703 ops/ms
[java] BSTBench.multiArrayBinarySeek 256 thrpt 16 667.122 ±
210.476 ops/ms
[java] BSTBench.multiArrayBinarySeek 512 thrpt 16 192.777 ±
29.690 ops/ms
[java] BSTBench.multiArrayLinearSearch 4 thrpt 16 172888.358 ±
7778.132 ops/ms
[java] BSTBench.multiArrayLinearSearch16 thrpt 16 16703.622 ±
565.180 ops/ms
[java] BSTBench.multiArrayLinearSearch64 thrpt 161096.093 ±
33.050 ops/ms
[java] BSTBench.multiArrayLinearSearch 256 thrpt 16 84.511 ±
2.776 ops/ms
[java] BSTBench.multiArrayLinearSearch 512 thrpt 16 22.130 ±
0.714 ops/ms
{code}
> Faster Memtable map
> ---
>
> Key: CASSANDRA-7282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benedict
>Assignee: Michael Burman
>Priority: Major
> Labels: performance
> Fix For: 4.x
>
> Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg,
> run1.svg, writes.svg
>
>
> Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in
> our memtables. Maintaining this is an O(lg(n)) operation; since the vast
> majority of users use a hash partitioner, it occurs to me we could maintain a
> hybrid ordered list / hash map. The list would impose the normal order on the
> collection, but a hash index would live alongside as part of the same data
> structure, simply mapping into the list and permitting O(1) lookups and
> inserts.
> I've chosen to implement this initial version as a linked-list node per item,
> but we can optimise this in future by storing fatter nodes that permit a
> cache-line's worth of hashes to be checked at once, further reducing the
> constant factor costs for lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14525) streaming failure during bootstrap makes new node into inconsistent state
[
https://issues.apache.org/jira/browse/CASSANDRA-14525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533961#comment-16533961
]
Jaydeepkumar Chovatia commented on CASSANDRA-14525:
---
[~KurtG] Thanks for making the changes!
Latest code changes looks good to me.
> streaming failure during bootstrap makes new node into inconsistent state
> -
>
> Key: CASSANDRA-14525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14525
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Major
> Fix For: 4.0, 2.2.x, 3.0.x
>
>
> If bootstrap fails for newly joining node (most common reason is due to
> streaming failure) then Cassandra state remains in {{joining}} state which is
> fine but Cassandra also enables Native transport which makes overall state
> inconsistent. This further creates NullPointer exception if auth is enabled
> on the new node, please find reproducible steps here:
> For example if bootstrap fails due to streaming errors like
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1256)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:894)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:660)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:573)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:330)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:695)
> [apache-cassandra-3.0.16.jar:3.0.16]
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:202)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:211)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:187)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:440)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.streaming.StreamSession.onError(StreamSession.java:540)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:307)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
> {quote}
> then variable [StorageService.java::dataAvailable
> |https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L892]
> will be {{false}}. Since {{dataAvailable}} is {{false}} hence it will not
> call [StorageService.java::finishJoiningRing
> |https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L933]
> and as a result
> [StorageService.java::doAuthSetup|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/ser
[jira] [Updated] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumanth Pasupuleti updated CASSANDRA-14557:
---
Description:
Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right now
- the system_auth table for example is created with RF=1 (to take into account
single node setups afaict from CASSANDRA-5112), and a user can further create a
keyspace with RF=1 posing availability and streaming risks (e.g. rebuild).
I propose we add two configuration options in cassandra.yaml:
# {{default_keyspace_rf}} (default: 1) - If replication factors are not
specified, use this number.
# {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
creating a keyspace with an RF less than what is configured
These settings could further be re-used to:
* Provide defaults for new keyspaces created with SimpleStrategy or
NetworkTopologyStrategy (CASSANDRA-14303)
* Make the automatic token [allocation
algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
interface more intuitive allowing easy use of the new token allocation
algorithm.
At the end of the day, if someone really wants to allow RF=1, they simply don’t
set the setting. For backwards compatibility the default remains 1 and C* would
create with RF=1, and would default to current behavior of allowing any RF on
keyspaces.
was:
Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right now
- the system_auth table for example is created with RF=1 (to take into account
single node setups afaict from CASSANDRA-5112), and a user can further create a
keyspace with RF=1 posing availability and streaming risks (e.g. rebuild).
I propose we add two configuration options in cassandra.yaml:
# {{default_keyspace_rf}} (default: 1) - If replication factors are not
specified, use this number.
# {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
creating a keyspace with an RF less than what is configured
These settings could further be re-used to:
* Provide defaults for new keyspaces created with SimpleStrategy or
NetworkTopologyStrategy (CASSANDRA-14303)
* Make the automatic token allocation algorithm interface more intuitive
allowing easy use of the new token allocation algorithm.
At the end of the day, if someone really wants to allow RF=1, they simply don’t
set the setting. For backwards compatibility the default remains 1 and C* would
create with RF=1, and would default to current behavior of allowing any RF on
keyspaces.
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533908#comment-16533908
]
Sumanth Pasupuleti commented on CASSANDRA-14557:
[~jeromatron] yes it goes beyond, in the sense.
* CASSANDRA-14303 focuses on not having to mention all the required
datacenters during keyspace creation, rather leaving it to C* to figure out the
data centers, while this ticket focuses on replication factor
* default_keyspace_rf can work complementary to CASSANDRA-14303 in the sense,
if user does not specify replication_factor during keyspace creation,
default_keyspace_rf could be used.
* default_keyspace_rf would be applicable for C* system keyspace creations
(like system_auth) in addition to user created keyspaces
* required_minimum_keyspace_rf is a configuration that will prevent any
keyspace creations with an rf lower than what is configured
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token allocation algorithm interface more intuitive
> allowing easy use of the new token allocation algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14252) Use zero as default score in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-14252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533909#comment-16533909 ] Jay Zhuang commented on CASSANDRA-14252: The change is reverted from 3.0 and 3.11 branches. More details: CASSANDRA-14555 > Use zero as default score in DynamicEndpointSnitch > -- > > Key: CASSANDRA-14252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14252 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Dikang Gu >Assignee: Dikang Gu >Priority: Major > Fix For: 4.0 > > Attachments: IMG_3180.jpg > > > The problem I want to solve is that I found in our deployment, one slow but > alive data node can slow down the whole cluster, even caused timeout of our > requests. > We are using DynamicEndpointSnitch, with badness_threshold 0.1. I expect the > DynamicEndpointSnitch switch to sortByProximityWithScore, if local data node > latency is too high. > I added some debug log, and figured out that in a lot of cases, the score > from remote data node was not populated, so the fallback to > sortByProximityWithScore never happened. That's why a single slow data node, > can cause huge problems to the whole cluster. > In this jira, I'd like to use zero as default score, so that we will get a > chance to try remote data node, if local one is slow. > I tested it in our test cluster, it improved the client latency in single > slow data node case significantly. > I flag this as a Bug, because it caused problems to our use cases multiple > times. > logs === > _2018-02-21_23:08:57.54145 WARN 23:08:57 [RPC-Thread:978]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [1.0]_ > _2018-02-21_23:08:57.54319 WARN 23:08:57 [RPC-Thread:967]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [0.0]_ > _2018-02-21_23:08:57.55111 WARN 23:08:57 [RPC-Thread:453]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [1.0]_ > _2018-02-21_23:08:57.55687 WARN 23:08:57 [RPC-Thread:753]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [1.0]_ > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14252) Use zero as default score in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-14252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Zhuang updated CASSANDRA-14252: --- Fix Version/s: (was: 3.11.3) (was: 3.0.17) > Use zero as default score in DynamicEndpointSnitch > -- > > Key: CASSANDRA-14252 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14252 > Project: Cassandra > Issue Type: Bug > Components: Coordination >Reporter: Dikang Gu >Assignee: Dikang Gu >Priority: Major > Fix For: 4.0 > > Attachments: IMG_3180.jpg > > > The problem I want to solve is that I found in our deployment, one slow but > alive data node can slow down the whole cluster, even caused timeout of our > requests. > We are using DynamicEndpointSnitch, with badness_threshold 0.1. I expect the > DynamicEndpointSnitch switch to sortByProximityWithScore, if local data node > latency is too high. > I added some debug log, and figured out that in a lot of cases, the score > from remote data node was not populated, so the fallback to > sortByProximityWithScore never happened. That's why a single slow data node, > can cause huge problems to the whole cluster. > In this jira, I'd like to use zero as default score, so that we will get a > chance to try remote data node, if local one is slow. > I tested it in our test cluster, it improved the client latency in single > slow data node case significantly. > I flag this as a Bug, because it caused problems to our use cases multiple > times. > logs === > _2018-02-21_23:08:57.54145 WARN 23:08:57 [RPC-Thread:978]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [1.0]_ > _2018-02-21_23:08:57.54319 WARN 23:08:57 [RPC-Thread:967]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [0.0]_ > _2018-02-21_23:08:57.55111 WARN 23:08:57 [RPC-Thread:453]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [1.0]_ > _2018-02-21_23:08:57.55687 WARN 23:08:57 [RPC-Thread:753]: > sortByProximityWithBadness: after sorting by proximity, addresses order > change to [ip1, ip2], with scores [1.0]_ > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14555) Verify effect of CASSANDRA-14252 on streaming endpoint selection
[
https://issues.apache.org/jira/browse/CASSANDRA-14555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533906#comment-16533906
]
Jay Zhuang commented on CASSANDRA-14555:
Reverted.
cc. [~dikanggu]
> Verify effect of CASSANDRA-14252 on streaming endpoint selection
>
>
> Key: CASSANDRA-14555
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14555
> Project: Cassandra
> Issue Type: Task
> Components: Streaming and Messaging
>Reporter: Sam Tunnicliffe
>Priority: Major
> Fix For: 4.x
>
>
> CASSANDRA-14252 makes a slight change to {{DynamicEndpointSnitch}} so that it
> is somewhat more likely a replica in a remote DC is contacted when replicas
> in the local DC are considered degraded. This seems reasonable on the read
> path, but it could also affect selection of endpoints for streaming and cross
> DC streaming is probably something that operators want to control more
> tightly. To be clear, I’m not 100% sure that this is actually an issue, but
> I’d like to have some investigation into it before we ship a change to
> default behaviour.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[2/6] cassandra git commit: Revert "use zero as default score in DynamicEndpointSnitch" from 3.0 and 3.11
Revert "use zero as default score in DynamicEndpointSnitch" from 3.0 and 3.11
This reverts commit 15bd10afbfc5eda024e7048438b00bfc81a9e3ea.
More details CASSANDRA-14555
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8ead7af1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8ead7af1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8ead7af1
Branch: refs/heads/cassandra-3.11
Commit: 8ead7af140c778542d3ea1244675320cd22b3042
Parents: a4b8d1e
Author: Jay Zhuang
Authored: Thu Jul 5 09:38:17 2018 -0700
Committer: Jay Zhuang
Committed: Thu Jul 5 09:38:17 2018 -0700
--
CHANGES.txt| 1 -
src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 2 +-
.../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00944dc..6f6ae20 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -19,7 +19,6 @@
* Handle all exceptions when opening sstables (CASSANDRA-14202)
* Handle incompletely written hint descriptors during startup
(CASSANDRA-14080)
* Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
- * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
* Respect max hint window when hinting for LWT (CASSANDRA-14215)
* Adding missing WriteType enum values to v3, v4, and v5 spec
(CASSANDRA-13697)
* Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 5356e8c..8c255f5 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -186,7 +186,7 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
{
Double score = scores.get(inet);
if (score == null)
-score = 0.0;
+continue;
subsnitchOrderedScores.add(score);
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
--
diff --git
a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
index 866cd82..af7dc17 100644
--- a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
+++ b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
@@ -92,7 +92,7 @@ public class DynamicEndpointSnitchTest
assertEquals(order, dsnitch.getSortedListByProximity(self,
Arrays.asList(host1, host2, host3, host4)));
setScores(dsnitch, 20, hosts, 10, 10, 10);
-order = Arrays.asList(host4, host1, host2, host3);
+order = Arrays.asList(host1, host2, host3, host4);
assertEquals(order, dsnitch.getSortedListByProximity(self,
Arrays.asList(host1, host2, host3, host4)));
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[5/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/847b8432 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/847b8432 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/847b8432 Branch: refs/heads/cassandra-3.11 Commit: 847b84323962b57699ccbbad21207c85ab392681 Parents: 942fe3f 8ead7af Author: Jay Zhuang Authored: Thu Jul 5 09:42:05 2018 -0700 Committer: Jay Zhuang Committed: Thu Jul 5 09:58:31 2018 -0700 -- CHANGES.txt| 1 - src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 2 +- .../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/847b8432/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/847b8432/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/847b8432/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk
Merge branch 'cassandra-3.11' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/28217f85 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/28217f85 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/28217f85 Branch: refs/heads/trunk Commit: 28217f8576d416fa8fff9f695058750e2bb943df Parents: 9e3b886 847b843 Author: Jay Zhuang Authored: Thu Jul 5 10:01:12 2018 -0700 Committer: Jay Zhuang Committed: Thu Jul 5 10:01:12 2018 -0700 -- -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[3/6] cassandra git commit: Revert "use zero as default score in DynamicEndpointSnitch" from 3.0 and 3.11
Revert "use zero as default score in DynamicEndpointSnitch" from 3.0 and 3.11
This reverts commit 15bd10afbfc5eda024e7048438b00bfc81a9e3ea.
More details CASSANDRA-14555
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8ead7af1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8ead7af1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8ead7af1
Branch: refs/heads/trunk
Commit: 8ead7af140c778542d3ea1244675320cd22b3042
Parents: a4b8d1e
Author: Jay Zhuang
Authored: Thu Jul 5 09:38:17 2018 -0700
Committer: Jay Zhuang
Committed: Thu Jul 5 09:38:17 2018 -0700
--
CHANGES.txt| 1 -
src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 2 +-
.../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00944dc..6f6ae20 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -19,7 +19,6 @@
* Handle all exceptions when opening sstables (CASSANDRA-14202)
* Handle incompletely written hint descriptors during startup
(CASSANDRA-14080)
* Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
- * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
* Respect max hint window when hinting for LWT (CASSANDRA-14215)
* Adding missing WriteType enum values to v3, v4, and v5 spec
(CASSANDRA-13697)
* Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 5356e8c..8c255f5 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -186,7 +186,7 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
{
Double score = scores.get(inet);
if (score == null)
-score = 0.0;
+continue;
subsnitchOrderedScores.add(score);
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
--
diff --git
a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
index 866cd82..af7dc17 100644
--- a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
+++ b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
@@ -92,7 +92,7 @@ public class DynamicEndpointSnitchTest
assertEquals(order, dsnitch.getSortedListByProximity(self,
Arrays.asList(host1, host2, host3, host4)));
setScores(dsnitch, 20, hosts, 10, 10, 10);
-order = Arrays.asList(host4, host1, host2, host3);
+order = Arrays.asList(host1, host2, host3, host4);
assertEquals(order, dsnitch.getSortedListByProximity(self,
Arrays.asList(host1, host2, host3, host4)));
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[4/6] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.11
Merge branch 'cassandra-3.0' into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/847b8432 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/847b8432 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/847b8432 Branch: refs/heads/trunk Commit: 847b84323962b57699ccbbad21207c85ab392681 Parents: 942fe3f 8ead7af Author: Jay Zhuang Authored: Thu Jul 5 09:42:05 2018 -0700 Committer: Jay Zhuang Committed: Thu Jul 5 09:58:31 2018 -0700 -- CHANGES.txt| 1 - src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 2 +- .../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/847b8432/CHANGES.txt -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/847b8432/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/847b8432/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[1/6] cassandra git commit: Revert "use zero as default score in DynamicEndpointSnitch" from 3.0 and 3.11
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 a4b8d1e9b -> 8ead7af14
refs/heads/cassandra-3.11 942fe3fb3 -> 847b84323
refs/heads/trunk 9e3b88646 -> 28217f857
Revert "use zero as default score in DynamicEndpointSnitch" from 3.0 and 3.11
This reverts commit 15bd10afbfc5eda024e7048438b00bfc81a9e3ea.
More details CASSANDRA-14555
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/8ead7af1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/8ead7af1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/8ead7af1
Branch: refs/heads/cassandra-3.0
Commit: 8ead7af140c778542d3ea1244675320cd22b3042
Parents: a4b8d1e
Author: Jay Zhuang
Authored: Thu Jul 5 09:38:17 2018 -0700
Committer: Jay Zhuang
Committed: Thu Jul 5 09:38:17 2018 -0700
--
CHANGES.txt| 1 -
src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java | 2 +-
.../org/apache/cassandra/locator/DynamicEndpointSnitchTest.java| 2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 00944dc..6f6ae20 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -19,7 +19,6 @@
* Handle all exceptions when opening sstables (CASSANDRA-14202)
* Handle incompletely written hint descriptors during startup
(CASSANDRA-14080)
* Handle repeat open bound from SRP in read repair (CASSANDRA-14330)
- * Use zero as default score in DynamicEndpointSnitch (CASSANDRA-14252)
* Respect max hint window when hinting for LWT (CASSANDRA-14215)
* Adding missing WriteType enum values to v3, v4, and v5 spec
(CASSANDRA-13697)
* Don't regenerate bloomfilter and summaries on startup (CASSANDRA-11163)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
--
diff --git a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
index 5356e8c..8c255f5 100644
--- a/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
+++ b/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java
@@ -186,7 +186,7 @@ public class DynamicEndpointSnitch extends
AbstractEndpointSnitch implements ILa
{
Double score = scores.get(inet);
if (score == null)
-score = 0.0;
+continue;
subsnitchOrderedScores.add(score);
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/8ead7af1/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
--
diff --git
a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
index 866cd82..af7dc17 100644
--- a/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
+++ b/test/unit/org/apache/cassandra/locator/DynamicEndpointSnitchTest.java
@@ -92,7 +92,7 @@ public class DynamicEndpointSnitchTest
assertEquals(order, dsnitch.getSortedListByProximity(self,
Arrays.asList(host1, host2, host3, host4)));
setScores(dsnitch, 20, hosts, 10, 10, 10);
-order = Arrays.asList(host4, host1, host2, host3);
+order = Arrays.asList(host1, host2, host3, host4);
assertEquals(order, dsnitch.getSortedListByProximity(self,
Arrays.asList(host1, host2, host3, host4)));
}
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[ https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533884#comment-16533884 ] Benedict commented on CASSANDRA-7282: - Great, thanks. The mismatch in expectations is probably because this is not the optimal way to implement a binary search variant. Ideally it would have two (or three) backing arrays, as opposed to a backing array of nodes. One primitive array of one side of bounds (e.g. lower bounds) to search on; another of keys, and another primitive array of the opposing bounds to filter results (or if the bounds are encoded in the keys already, that could be skipped). Do you mind adding that variant to the comparison? > Faster Memtable map > --- > > Key: CASSANDRA-7282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7282 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Michael Burman >Priority: Major > Labels: performance > Fix For: 4.x > > Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg, > run1.svg, writes.svg > > > Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in > our memtables. Maintaining this is an O(lg(n)) operation; since the vast > majority of users use a hash partitioner, it occurs to me we could maintain a > hybrid ordered list / hash map. The list would impose the normal order on the > collection, but a hash index would live alongside as part of the same data > structure, simply mapping into the list and permitting O(1) lookups and > inserts. > I've chosen to implement this initial version as a linked-list node per item, > but we can optimise this in future by storing fatter nodes that permit a > cache-line's worth of hashes to be checked at once, further reducing the > constant factor costs for lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533856#comment-16533856
]
Jeremy Hanna commented on CASSANDRA-14557:
--
Does this go beyond CASSANDRA-14303?
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Minor
> Fix For: 4.0
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token allocation algorithm interface more intuitive
> allowing easy use of the new token allocation algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[ https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533829#comment-16533829 ] Michael Burman commented on CASSANDRA-7282: --- Here you go: https://gist.github.com/burmanm/7fb14589d5c0d11ae79c018bd7849653 > Faster Memtable map > --- > > Key: CASSANDRA-7282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7282 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Michael Burman >Priority: Major > Labels: performance > Fix For: 4.x > > Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg, > run1.svg, writes.svg > > > Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in > our memtables. Maintaining this is an O(lg(n)) operation; since the vast > majority of users use a hash partitioner, it occurs to me we could maintain a > hybrid ordered list / hash map. The list would impose the normal order on the > collection, but a hash index would live alongside as part of the same data > structure, simply mapping into the list and permitting O(1) lookups and > inserts. > I've chosen to implement this initial version as a linked-list node per item, > but we can optimise this in future by storing fatter nodes that permit a > cache-line's worth of hashes to be checked at once, further reducing the > constant factor costs for lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[ https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533770#comment-16533770 ] Benedict commented on CASSANDRA-7282: - Could you share the code you used for this benchmark? The result is counterintuitive. > Faster Memtable map > --- > > Key: CASSANDRA-7282 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7282 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict >Assignee: Michael Burman >Priority: Major > Labels: performance > Fix For: 4.x > > Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg, > run1.svg, writes.svg > > > Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in > our memtables. Maintaining this is an O(lg(n)) operation; since the vast > majority of users use a hash partitioner, it occurs to me we could maintain a > hybrid ordered list / hash map. The list would impose the normal order on the > collection, but a hash index would live alongside as part of the same data > structure, simply mapping into the list and permitting O(1) lookups and > inserts. > I've chosen to implement this initial version as a linked-list node per item, > but we can optimise this in future by storing fatter nodes that permit a > cache-line's worth of hashes to be checked at once, further reducing the > constant factor costs for lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7282) Faster Memtable map
[
https://issues.apache.org/jira/browse/CASSANDRA-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533582#comment-16533582
]
Michael Burman commented on CASSANDRA-7282:
---
Out of range tokens were also important for system tables as they do not follow
the normal ranges. I agree that this type of information should not be inside
the Memtable, but outside the Memtable. I however designed the patch to be
"plug-in" without touching other parts too much. There's certainly going to be
more overhead for one memtable per range, but that might not be an issue
depending on the amount of vnodes per node. Which then is part of the reason
for your next question. The tree is certainly an overkill, but I made it
because it behaves more predictably with the amount of vnodes currently in use:
{code:java}
[java] Benchmark (vnodes) Mode Cnt Score Error
Units
[java] BSTBench.binarySeek 4 thrpt 16 122117.853 ± 6815.672
ops/ms
[java] BSTBench.binarySeek 16 thrpt 16 22711.007 ± 691.020
ops/ms
[java] BSTBench.binarySeek 64 thrpt 16 4547.383 ± 180.749
ops/ms
[java] BSTBench.binarySeek 256 thrpt 16 892.406 ± 42.791
ops/ms
[java] BSTBench.binarySeek 512 thrpt 16 224.545 ± 6.469
ops/ms
[java] BSTBench.linearSearch 4 thrpt 16 214901.639 ± 3264.386
ops/ms
[java] BSTBench.linearSearch 16 thrpt 16 19594.770 ± 718.201
ops/ms
[java] BSTBench.linearSearch 64 thrpt 16 1302.657 ± 43.841
ops/ms
[java] BSTBench.linearSearch 256 thrpt 16 105.317 ± 2.950
ops/ms
[java] BSTBench.linearSearch 512 thrpt 16 25.932 ± 3.488
ops/ms
[java] BSTBench.treeSeek 4 thrpt 16 162053.915 ± 4228.035
ops/ms
[java] BSTBench.treeSeek 16 thrpt 16 31650.599 ± 789.500
ops/ms
[java] BSTBench.treeSeek 64 thrpt 16 5901.952 ± 137.575
ops/ms
[java] BSTBench.treeSeek 256 thrpt 16 1055.737 ± 22.786
ops/ms
[java] BSTBench.treeSeek 512 thrpt 16 208.169 ± 4.617
ops/ms
{code}
(The above test creates vnodes size of token ranges and then tries to find each
one in a random order) And the amount of code for binary search vs tree search
is almost equivalent. But between 4-256 it is a fast method (with linear search
being the quickest one for very small amount of token ranges). So I thought it
as a best "compromise".
> Faster Memtable map
> ---
>
> Key: CASSANDRA-7282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7282
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benedict
>Assignee: Michael Burman
>Priority: Major
> Labels: performance
> Fix For: 4.x
>
> Attachments: jasobrown-sample-run.txt, profile.yaml, reads.svg,
> run1.svg, writes.svg
>
>
> Currently we maintain a ConcurrentSkipLastMap of DecoratedKey -> Partition in
> our memtables. Maintaining this is an O(lg(n)) operation; since the vast
> majority of users use a hash partitioner, it occurs to me we could maintain a
> hybrid ordered list / hash map. The list would impose the normal order on the
> collection, but a hash index would live alongside as part of the same data
> structure, simply mapping into the list and permitting O(1) lookups and
> inserts.
> I've chosen to implement this initial version as a linked-list node per item,
> but we can optimise this in future by storing fatter nodes that permit a
> cache-line's worth of hashes to be checked at once, further reducing the
> constant factor costs for lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14541) Order of warning and custom payloads is unspecified in the protocol specification
[ https://issues.apache.org/jira/browse/CASSANDRA-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-14541: Reviewer: Alex Petrov > Order of warning and custom payloads is unspecified in the protocol > specification > - > > Key: CASSANDRA-14541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14541 > Project: Cassandra > Issue Type: Bug > Components: Documentation and Website >Reporter: Avi Kivity >Assignee: Avi Kivity >Priority: Trivial > Attachments: > v1-0001-Document-order-of-tracing-warning-and-custom-payl.patch > > > Section 2.2 of the protocol specification documents the types of tracing, > warning, and custom payloads, but does not document their order in the body. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14525) streaming failure during bootstrap makes new node into inconsistent state
[
https://issues.apache.org/jira/browse/CASSANDRA-14525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533547#comment-16533547
]
Kurt Greaves commented on CASSANDRA-14525:
--
Thanks [~chovatia.jayd...@gmail.com]. I figured it was unfair making you do all
the work so I made some changes myself. Basically we were still silently
failing with {{nodetool join}}, so I've added {{isBootstrapMode()}} to
{{StorageServiceMBean}} and {{NodeProbe}} and added a check for it in
{{Join.java}}. I've also tried to simplify some of the if statements (edge
cases are killing me) and added a bit of documentation. I also created a 3.11
branch from our changes as there were a few conflicts from 3.0.
Finally, I extended your dtest from CASSANDRA-14526 to cover the write_survey,
join and resume cases to be in line with the changes we've made, and also
changed the byteman rule to trigger on {{maybeCompleted()}} as it wasn't
consistently triggering on {{startStreamingFiles()}}
Now I think we're pretty much ready to go, but if you want to give my changes a
once over to make sure I haven't missed anything as I'm sure you're aware the
startup code is an absolute nightmare.
Also, I haven't run the whole dtest suite, but I've at least run all the
bootstrap dtests and they are all passing, so I'm taking that as a good sign.
||2.2||3.0||3.11||trunk||dtests||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...kgreav:14525-2.2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...kgreav:14525-3.0]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.11...kgreav:14525-3.11]|[branch|https://github.com/apache/cassandra/compare/trunk...kgreav:14525-trunk]|[branch|https://github.com/apache/cassandra-dtest/compare/master...kgreav:14526-trunk-k]|
|[!https://circleci.com/gh/kgreav/cassandra/tree/14525-2.2.svg?style=svg!
|https://circleci.com/gh/kgreav/cassandra/178]|[!https://circleci.com/gh/kgreav/cassandra/tree/14525-3.0.svg?style=svg!
|https://circleci.com/gh/kgreav/cassandra/181]|[!https://circleci.com/gh/kgreav/cassandra/tree/14525-3.11.svg?style=svg!
|https://circleci.com/gh/kgreav/cassandra/180]|[!https://circleci.com/gh/kgreav/cassandra/tree/14525-trunk.svg?style=svg!
|https://circleci.com/gh/kgreav/cassandra/183]|
> streaming failure during bootstrap makes new node into inconsistent state
> -
>
> Key: CASSANDRA-14525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14525
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Major
> Fix For: 4.0, 2.2.x, 3.0.x
>
>
> If bootstrap fails for newly joining node (most common reason is due to
> streaming failure) then Cassandra state remains in {{joining}} state which is
> fine but Cassandra also enables Native transport which makes overall state
> inconsistent. This further creates NullPointer exception if auth is enabled
> on the new node, please find reproducible steps here:
> For example if bootstrap fails due to streaming errors like
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
> ~[guava-18.0.jar:na]
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1256)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:894)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:660)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:573)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:330)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
> [apache-cassandra-3.0.16.jar:3.0.16]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:695)
> [apache-cassandra-3.0.16.jar:3.0.16]
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:85)
> ~[apache-cassandra-3.0.16.jar:3.0.16]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1310)
[4/6] cassandra git commit: Merge commit 'a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11' into cassandra-3.11
Merge commit 'a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11' into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/942fe3fb Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/942fe3fb Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/942fe3fb Branch: refs/heads/trunk Commit: 942fe3fb3d81b0f78164ab35c174130c2395a402 Parents: 49e63c2 a4b8d1e Author: Sylvain Lebresne Authored: Thu Jul 5 09:27:51 2018 +0200 Committer: Sylvain Lebresne Committed: Thu Jul 5 09:27:51 2018 +0200 -- -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[5/6] cassandra git commit: Merge commit 'a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11' into cassandra-3.11
Merge commit 'a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11' into cassandra-3.11 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/942fe3fb Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/942fe3fb Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/942fe3fb Branch: refs/heads/cassandra-3.11 Commit: 942fe3fb3d81b0f78164ab35c174130c2395a402 Parents: 49e63c2 a4b8d1e Author: Sylvain Lebresne Authored: Thu Jul 5 09:27:51 2018 +0200 Committer: Sylvain Lebresne Committed: Thu Jul 5 09:27:51 2018 +0200 -- -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[2/6] cassandra git commit: Fix build
Fix build
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a4b8d1e9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a4b8d1e9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a4b8d1e9
Branch: refs/heads/cassandra-3.11
Commit: a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11
Parents: 93012e4
Author: Sylvain Lebresne
Authored: Thu Jul 5 09:24:17 2018 +0200
Committer: Sylvain Lebresne
Committed: Thu Jul 5 09:24:17 2018 +0200
--
test/unit/org/apache/cassandra/db/CounterCellTest.java | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4b8d1e9/test/unit/org/apache/cassandra/db/CounterCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/CounterCellTest.java
b/test/unit/org/apache/cassandra/db/CounterCellTest.java
index 8859fc6..b4c7b2a 100644
--- a/test/unit/org/apache/cassandra/db/CounterCellTest.java
+++ b/test/unit/org/apache/cassandra/db/CounterCellTest.java
@@ -32,7 +32,6 @@ import org.apache.cassandra.config.ColumnDefinition;
import org.apache.cassandra.db.rows.BTreeRow;
import org.apache.cassandra.db.rows.BufferCell;
import org.apache.cassandra.db.rows.Cell;
-import org.apache.cassandra.db.rows.CellPath;
import org.apache.cassandra.db.rows.Cells;
import org.apache.cassandra.db.context.CounterContext;
import org.apache.cassandra.db.rows.Row;
@@ -292,10 +291,10 @@ public class CounterCellTest
ColumnFamilyStore cfs =
Keyspace.open(KEYSPACE1).getColumnFamilyStore(COUNTER1);
ColumnDefinition emptyColDef =
cfs.metadata.getColumnDefinition(ByteBufferUtil.bytes("val2"));
-BufferCell emptyCell = BufferCell.live(emptyColDef, 0,
ByteBuffer.allocate(0));
+BufferCell emptyCell = BufferCell.live(cfs.metadata, emptyColDef, 0,
ByteBuffer.allocate(0));
Row.Builder builder = BTreeRow.unsortedBuilder(0);
-
builder.newRow(Clustering.make(AsciiSerializer.instance.serialize("test")));
+builder.newRow(new
Clustering(AsciiSerializer.instance.serialize("test")));
builder.addCell(emptyCell);
Row row = builder.build();
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[3/6] cassandra git commit: Fix build
Fix build
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a4b8d1e9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a4b8d1e9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a4b8d1e9
Branch: refs/heads/trunk
Commit: a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11
Parents: 93012e4
Author: Sylvain Lebresne
Authored: Thu Jul 5 09:24:17 2018 +0200
Committer: Sylvain Lebresne
Committed: Thu Jul 5 09:24:17 2018 +0200
--
test/unit/org/apache/cassandra/db/CounterCellTest.java | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4b8d1e9/test/unit/org/apache/cassandra/db/CounterCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/CounterCellTest.java
b/test/unit/org/apache/cassandra/db/CounterCellTest.java
index 8859fc6..b4c7b2a 100644
--- a/test/unit/org/apache/cassandra/db/CounterCellTest.java
+++ b/test/unit/org/apache/cassandra/db/CounterCellTest.java
@@ -32,7 +32,6 @@ import org.apache.cassandra.config.ColumnDefinition;
import org.apache.cassandra.db.rows.BTreeRow;
import org.apache.cassandra.db.rows.BufferCell;
import org.apache.cassandra.db.rows.Cell;
-import org.apache.cassandra.db.rows.CellPath;
import org.apache.cassandra.db.rows.Cells;
import org.apache.cassandra.db.context.CounterContext;
import org.apache.cassandra.db.rows.Row;
@@ -292,10 +291,10 @@ public class CounterCellTest
ColumnFamilyStore cfs =
Keyspace.open(KEYSPACE1).getColumnFamilyStore(COUNTER1);
ColumnDefinition emptyColDef =
cfs.metadata.getColumnDefinition(ByteBufferUtil.bytes("val2"));
-BufferCell emptyCell = BufferCell.live(emptyColDef, 0,
ByteBuffer.allocate(0));
+BufferCell emptyCell = BufferCell.live(cfs.metadata, emptyColDef, 0,
ByteBuffer.allocate(0));
Row.Builder builder = BTreeRow.unsortedBuilder(0);
-
builder.newRow(Clustering.make(AsciiSerializer.instance.serialize("test")));
+builder.newRow(new
Clustering(AsciiSerializer.instance.serialize("test")));
builder.addCell(emptyCell);
Row row = builder.build();
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[1/6] cassandra git commit: Fix build
Repository: cassandra
Updated Branches:
refs/heads/cassandra-3.0 93012e43e -> a4b8d1e9b
refs/heads/cassandra-3.11 49e63c273 -> 942fe3fb3
refs/heads/trunk 243c371f4 -> 9e3b88646
Fix build
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/a4b8d1e9
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/a4b8d1e9
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/a4b8d1e9
Branch: refs/heads/cassandra-3.0
Commit: a4b8d1e9bc67eb0eff159b5b35902cab19e3fc11
Parents: 93012e4
Author: Sylvain Lebresne
Authored: Thu Jul 5 09:24:17 2018 +0200
Committer: Sylvain Lebresne
Committed: Thu Jul 5 09:24:17 2018 +0200
--
test/unit/org/apache/cassandra/db/CounterCellTest.java | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/a4b8d1e9/test/unit/org/apache/cassandra/db/CounterCellTest.java
--
diff --git a/test/unit/org/apache/cassandra/db/CounterCellTest.java
b/test/unit/org/apache/cassandra/db/CounterCellTest.java
index 8859fc6..b4c7b2a 100644
--- a/test/unit/org/apache/cassandra/db/CounterCellTest.java
+++ b/test/unit/org/apache/cassandra/db/CounterCellTest.java
@@ -32,7 +32,6 @@ import org.apache.cassandra.config.ColumnDefinition;
import org.apache.cassandra.db.rows.BTreeRow;
import org.apache.cassandra.db.rows.BufferCell;
import org.apache.cassandra.db.rows.Cell;
-import org.apache.cassandra.db.rows.CellPath;
import org.apache.cassandra.db.rows.Cells;
import org.apache.cassandra.db.context.CounterContext;
import org.apache.cassandra.db.rows.Row;
@@ -292,10 +291,10 @@ public class CounterCellTest
ColumnFamilyStore cfs =
Keyspace.open(KEYSPACE1).getColumnFamilyStore(COUNTER1);
ColumnDefinition emptyColDef =
cfs.metadata.getColumnDefinition(ByteBufferUtil.bytes("val2"));
-BufferCell emptyCell = BufferCell.live(emptyColDef, 0,
ByteBuffer.allocate(0));
+BufferCell emptyCell = BufferCell.live(cfs.metadata, emptyColDef, 0,
ByteBuffer.allocate(0));
Row.Builder builder = BTreeRow.unsortedBuilder(0);
-
builder.newRow(Clustering.make(AsciiSerializer.instance.serialize("test")));
+builder.newRow(new
Clustering(AsciiSerializer.instance.serialize("test")));
builder.addCell(emptyCell);
Row row = builder.build();
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[6/6] cassandra git commit: Merge branch 'cassandra-3.11' into trunk
Merge branch 'cassandra-3.11' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9e3b8864 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9e3b8864 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9e3b8864 Branch: refs/heads/trunk Commit: 9e3b88646ff4f97601baf40be7fb708ebb3f7fed Parents: 243c371 942fe3f Author: Sylvain Lebresne Authored: Thu Jul 5 09:30:03 2018 +0200 Committer: Sylvain Lebresne Committed: Thu Jul 5 09:30:03 2018 +0200 -- -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
