av9ash/GitBugs huggingface dataset:
Bug: Fix Double Type issues in the Gossiper#maybeGossipToCMS
Status: Open
Priority: Low
Created: 23/Feb/24 09:44

_*issue-1:*_

if liveEndpoints.size()=unreachableEndpoints.size()=0; probability will be {*}_Infinity_{*}.
randDbl <= probability will always be true, then sendGossip

_*issue-2:*_ 

comparing two double is safe by using *<* or {*}>{*}. However missing accuracy will happen if we compare the equality of two double by intuition({*}={*}). For example:
{code:java}
double probability = 0.1;
double randDbl = 0.10000000000000001; // Slightly greater than probability
if (randDbl <= probability)
{
    System.out.println("randDbl <= probability(always here)");
}
else
{
    System.out.println("randDbl > probability");
}
{code}
A good example from: _*Gossiper#maybeGossipToUnreachableMember*_
{code:java}
if (randDbl < prob)
{
sendGossip(message, Sets.filter(unreachableEndpoints.keySet(),
                                ep -> !isDeadState(getEndpointStateMap().get(ep))));
}{code}
Bug: Fix Contributing Code Changes page
Status: Open
Priority: Low
Created: 14/Feb/24 14:53

Fix "Choosing the Right Branches to Work on" section. Currently it says 2.1 and 2.2 critical bug fixes when the community does not maintain at this point those versions. Also, we already release 4.0 and 4.1, the code freeze should move to 5.0. 

I would like to suggest we update the page by saying - any version which is not EOL and it is already GA - critical bug fixes, any post-alpha version which is not GA yet - code freeze, no new features or improvements; stabilization period. 

We can also mention this info can be inferred from the Downloads page as that one is updated on every release.
Bug: "comments" keyword on docs page should be "comment"
Status: Triage Needed
Priority: Low
Created: 09/Jan/24 13:59

Low-priority nitpick: the CREATE TABLE [docs page|[https://cassandra.apache.org/doc/latest/cassandra/reference/cql-commands/create-table.html#table_options]] has

{{comments = 'some text that describes the table'}}

with plural `comments`, while the correct keyword to use is `comment` (singular).

Using the plural form would result in the following error when running the DDL statement: _SyntaxException: Unknown property 'comments'_
Bug: Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
Status: Open
Priority: Low
Created: 18/Jan/24 16:49

It came up in a review that I had missed some style changes in [CASSANDRA-18857] (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).  Chatting with [~smiklosovic] we agreed that it would be nice if we could enforce this in checkstyle, so we wouldn't need to be dependent on this being caught in review.

The change for this is effectively:

{code}
index 8b81f21281..9bd22dc1ac 100644
--- a/.build/checkstyle.xml
+++ b/.build/checkstyle.xml
@@ -179,6 +179,10 @@
       <message key="matchxpath.match"
                value="'Deprecated annotation must provide 'since' value."/>
     </module>
+    <module name="LeftCurly">
+        <property name="option" value="nl"/>
+        <property name="tokens" value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
+    </module>
   </module>

 </module>
{code}

Notably, we would allow braces on the same lines for lambdas as per the [project guidelines|https://cassandra.apache.org/_/development/code_style.html] on code formatting:

{quote}
 {{{}} and {{}}} are placed on a new line except when empty or opening a multi-line lambda expression. Braces may be elided to a depth of one if the condition or loop guards a single expression.
{quote}

There are 594 violations and 211 source files that would need to be adjusted.   I may play with the rules a little bit more to get this right.

I would like to propose that we change all files that are not imported from other projects (there are a few, such as src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress changes for), but we would change others.  

I'll make a patch with the changes send a small proposal to the mailing list as it could be disruptive to make a bunch of tiny changes, and depending on timing there may be a better time to make a change like this.

We should make this change only on trunk.
Bug: Implement node bootstrap in in-JVM tests
Status: Resolved
Priority: High
Resolution: Fixed
Created: 10/Jan/20 16:45
Resolved: 05/Feb/20 10:59

Currently, we do not have an ability to add nodes to the running in-jvm cluster, either by bootstrap or replacement process. We need to add an ability to add nodes in inactive state, start them up, and bootstrap to test streaming, range movements, and operations that occur during these processes.
Bug: Expose Cassandra related system properties in a virtual table
Status: Resolved
Priority: High
Resolution: Fixed
Created: 02/Mar/20 21:11
Resolved: 05/Mar/20 07:42

Allow viewing Cassandra related system properties.

Viewing yaml config settings, as implemented by {{SettingsTable}} in CASSANDRA-14573, is not enough for certain third-party tool use-cases. There are a number of system properties that can be defined that contribute to the configuration set that Cassandra runs on.

An example of such a use-case is described in CASSANDRA-15339. JMX ports need to be discovered, especially in 4.0 where multiple nodes can run on one ipaddress. Unlike the native port that is through gossip discoverable, the jmx port is not. The jmx port is also not available via the SettingsTable. With this patch and {{SystemPropertiesTable}} it becomes possible to first discover all the native ports in the cluster and against each then discover each node's jmx port.
Bug: Improve docs on disk_access_mode, specifically post CASSANDRA-8464
Status: Open
Priority: Normal
Created: 29/Jan/20 12:21

h2.  Background
[~tsteinmaurer] brought up [on Slack|https://the-asf.slack.com/archives/CJZLTM05A/p1580298424288700] that they've been hit by the `oom-killer` as a result of SSTables being mmaped.
h2. Action
Based on feedback from Thomas Steinmaurer, Jean Carlo & Sam Kearon, I am going to push the info I've written in this KB article to the official docs – [Increased memory use on nodes after upgrading to DSE 5.0 or DSE 5.1|https://support.datastax.com/s/article/Increased-memory-use-on-nodes-after-upgrading-to-DSE-50-or-DSE-51].

I will revise it specifically for affected OSS versions.
Bug: Counter tables should use a 4KB chunk length by default
Status: Open
Priority: Normal
Created: 04/Mar/20 00:16

One of the issues I found when using counters is throughput gets significantly limited due to the default chunk length.  When tuning from 64 to 4, I saw a massive improvement in both throughput and latency.

Our default chunk length is 16, which is fine for general purpose tables, but since tables with counters are special purpose we should give users this optimization automatically.
Bug: Repair -full sets "repairedAt" value
Status: Triage Needed
Priority: Normal
Created: 18/Jan/20 00:06

{code:java}
src/java/org/apache/cassandra/service/ActiveRepairService.java:{code}
{code:java}
* we only want to set repairedAt for incremental repairs including all replicas for a token range. For non-global
* incremental repairs, forced incremental repairs, and full repairs, the UNREPAIRED_SSTABLE value will prevent
* sstables from being promoted to repaired or preserve the repairedAt/pendingRepair values, respectively.{code}

Verified in 3.11.5:
{code:java}
$ for f in *Data.db; do echo $f; sudo /usr/bin/sstablemetadata $f |grep -i repaired; done
md-10-big-Data.db
Repaired at: 0
md-5-big-Data.db
Repaired at: 0
md-6-big-Data.db
Repaired at: 0
md-7-big-Data.db
Repaired at: 0
md-8-big-Data.db
Repaired at: 0
md-9-big-Data.db
Repaired at: 0

$ nodetool repair -full 
[2020-01-17 00:25:35,192] Starting repair command #1 (e0edeee0-38bf-11ea-b3f5-891068749d18), repairing keyspace ext_alt_live with repair options (parallelism: parallel, primary range: false, incremental: false, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 3, pull repair: false)
[2020-01-17 00:27:51,874] Repair session e1930880-38bf-11ea-b3f5-891068749d18 for range [(3074457345618258602,-9223372036854775808], (-9223372036854775808,-3074457345618258603], (-3074457345618258603,3074457345618258602]] finished (progress: 71%)
[2020-01-17 00:27:51,920] Repair completed successfully
[2020-01-17 00:27:51,925] Repair command #1 finished in 2 minutes 16 seconds
[2020-01-17 00:27:51,980] Replication factor is 1. No repair is needed for keyspace 'system_auth'
[2020-01-17 00:27:52,003] Starting repair command #2 (327adb10-38c0-11ea-b3f5-891068749d18), repairing keyspace system_traces with repair options (parallelism: parallel, primary range: false, incremental: false, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], # of ranges: 2, pull repair: false)
[2020-01-17 00:27:52,052] Repair session 327d4c10-38c0-11ea-b3f5-891068749d18 for range [(3074457345618258602,-9223372036854775808]] finished (progress: 83%)
[2020-01-17 00:27:52,081] Repair session 327dc140-38c0-11ea-b3f5-891068749d18 for range [(-3074457345618258603,3074457345618258602]] finished (progress: 100%)
[2020-01-17 00:27:52,086] Repair completed successfully
[2020-01-17 00:27:52,090] Repair command #2 finished in 0 seconds

$ for f in *Data.db; do echo $f; sudo /usr/bin/sstablemetadata $f |grep -i repaired; done
md-11-big-Data.db
Repaired at: 0
md-12-big-Data.db
Repaired at: 0
md-13-big-Data.db
Repaired at: 1579220735212
md-14-big-Data.db
Repaired at: 1579220735212
md-15-big-Data.db
Repaired at: 1579220735212
md-16-big-Data.db
Repaired at: 1579220735212{code}
Bug: Ensure repaired data tracking reads a consistent amount of data across replicas
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Feb/20 14:43
Resolved: 16/Apr/20 17:47

When generating a digest for repaired data tracking, the amount of repaired data that needs to be read may depend on the unrepaired data on the replica. As this may vary between replicas, digest mismatches can be reported even though the repaired data may actually be in sync.

For example, two replicas, A & B and a table like
{code}
CREATE TABLE t  (pk int, ck int, PRIMARY KEY (pk, ck)) WITH CLUSTERING ORDER BY ck DESC; 

Unrepaired
===========
Instance A
(0, 5)

Instance B
(0, 6)
(0, 5)


Repaired (Both A & B)
=========
(0, 4)
(0, 3)
(0, 2)
(0, 1)
(0, 0)

SELECT * FROM tbl WHERE pk = 0 LIMIT 3;
{code}
Instance A would read (0, 5) from the unrepaired set and (0, 4) (0, 3) from the repaired set. 
 Instance B would read (0, 6) (0, 5) from its unrepaired set and just (0, 4) from repaired data.

Unrepaired row/range/partition tombstones shadowing repaired data and present on some replicas but not others will have the opposite effect, with more repaired data being read in comparison.


 To fix this, when repaired data tracking is in effect each replica needs to overread during a full data read. Replicas should read up to {{LIMIT}} (i.e. the {{DataLimit}} of the {{ReadCommand}}) from the repaired set, regardless of how much is read from the unrepaired data. At the point where that amount of repaired data has been read, replica should stop updating the digest. So if unrepaired tombstones cause more than {{LIMIT}} repaired data to be read, the digest is only calculated over the first {{LIMIT}}-worth of repaired data.
Bug: Utilising BTree Improvements
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jan/20 21:16
Resolved: 07/Jul/22 12:36

This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage produced by a number of common operations, by employing {{transformAndFilter}}, {{transform}} and {{FastBuilder}}

* {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with {{BTree.transform}}, so no special builders are necessary; 
** {{Rows.copy}} removed
* {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}} reconciler
** Zero-allocations if result of merge is same as {{existing}}
** Fewer comparisons
* {{ColumnData}} reconciler implemented in same manner
** {{Cells.reconcileComplex}} is retired
** {{ComplexColumnData}} reconciliation now
*** Garbage-free if the merge has no effect
*** Always fewer allocations
*** Fewer comparisons
* {{FastBuilder}} employed widely:
** {{ClusteringIndexNamesFilter}} deserialization
** {{Columns}} deserialization
** {{PartitionUpdate}} deserialization
** {{AbstractBTreePartition}} construction
** Misc others

The upshot of this work when combined with the proposed patch for CASSANDRA-15367 has a dramatic impact on operations over collection types - under contention, as much as 100x improved throughput, and hundreds of megabytes of reduced allocations.  For all operations, allocations under contention and no contention are significantly reduced and throughput improved.
Bug: cassandra-stress in user profile mode fails on handling set<set<int>> columns
Status: Open
Priority: Normal
Created: 25/Feb/20 12:38

Reason:
 c-s reads metadata from database, and build column generator from it.
 But this logic is build in a way so that it does not support generator recursion, which is necessary to support embedded collections.

Fix:
 This fix is simple exclude this type of columns from being processed.

Steps to reproduce:
 # docker run -d --name cassandra cassandra:latest
 # cassandra-stress user profile=cs_no_mv_basic_profile.yaml ops'(insert=1)' cl=ONE n=20 -pop seq=1..10000000 -port jmx=6868 -mode cql3 native -rate threads=2 -node 172.17.0.2
 # docker exec -ti cassandra cqlsh -e 'ALTER TABLE mview.users ADD ( asdasdasd set<frozen<set>>);'
 # cassandra-stress user profile=cs_no_mv_basic_profile.yaml ops'(insert=1)' cl=ONE n=20 -pop seq=1..10000000 -port jmx=6868 -mode cql3 native -rate threads=2 -node 172.17.0.2

Result:
 Extra Schema Definitions: null
 Generator Configs:
 password: Size: Fixed: key=80;
 last_name: Size: Uniform: min=1,max=32;
 id: Size: Uniform: min=1,max=10;
 first_name: Size: Fixed: key=16;
 email: Size: Uniform: min=16,max=50;
 username: Size: Uniform: min=10,max=30;
 Query Definitions:
 read1: CQL:select * from mview.users where id = ? LIMIT 10;Fields:samerow;
 Token Range Queries:
 Insert Settings:
 partitions: fixed(1)
 batchtype: UNLOGGED
 Connected to cluster: , max pending requests per connection 128, max connections per host 8
 Datacenter: datacenter1; Host: /172.17.0.2:9042; Rack: rack1
 Created schema. Sleeping 1s for propagation.
 java.lang.NullPointerException
 at org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:760)
 at org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:800)
 at org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:800)
 at org.apache.cassandra.stress.StressProfile$ColumnInfo.getGenerator(StressProfile.java:755)
 at org.apache.cassandra.stress.StressProfile$GeneratorFactory.get(StressProfile.java:733)
 at org.apache.cassandra.stress.StressProfile$GeneratorFactory.newGenerator(StressProfile.java:726)
 at org.apache.cassandra.stress.StressProfile.newGenerator(StressProfile.java:696)
 at org.apache.cassandra.stress.StressProfile.printSettings(StressProfile.java:126)
 at org.apache.cassandra.stress.settings.StressSettings.lambda$printSettings$1(StressSettings.java:311)
 at java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
 at org.apache.cassandra.stress.settings.StressSettings.printSettings(StressSettings.java:311)
 at org.apache.cassandra.stress.Stress.run(Stress.java:95)
 at org.apache.cassandra.stress.Stress.main(Stress.java:62)
Bug: Read failure due to exception from metrics-core dependency
Status: In Progress
Priority: Normal
Created: 06/Jan/20 21:13

Stacktrace
{code:java}
Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
java.util.NoSuchElementException: null
	at java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053) ~[na:1.8.0_222]
	at com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102) ~[metrics-core-2.2.0.jar:na]
	at com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81) ~[metrics-core-2.2.0.jar:na]
	at com.yammer.metrics.core.Histogram.update(Histogram.java:110) ~[metrics-core-2.2.0.jar:na]
	at com.yammer.metrics.core.Timer.update(Timer.java:198) ~[metrics-core-2.2.0.jar:na]
	at com.yammer.metrics.core.Timer.update(Timer.java:76) ~[metrics-core-2.2.0.jar:na]
	at org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_222]
	at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [nf-cassandra-2.1.19.10.jar:2.1.19.10]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
{code}

This [issue|https://github.com/dropwizard/metrics/issues/1278] has been [fixed|https://github.com/dropwizard/metrics/pull/1436] in [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].

This is observed on a 2.1.19 cluster, but this would impact pretty much any version of C* since we depend on lower versions of metrics-core that do not have the fix.
Bug: Potential Overflow in DatabaseDescriptor Functions That Convert Between KB/MB & Bytes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Jan/20 12:10
Resolved: 05/Feb/20 19:59

{{DatabaseDescriptor}} has several functions that convert between user supplied sizes in KB/MB and bytes. These are implemented without much consistency and, while unlikely, several have the potential to overflow since validation on the input is missing. Meanwhile, some widen the number to a long correctly. Options include: widening in all places or simply doing better validation on start up — currently only the lower bound of the valid range is checked for many of these fields.

List of Affected {{DatabaseDescriptor}} Methods:
 * {{getColumnIndexSize}}
 * {{getColumnIndexCacheSize}}
 * {{getBatchSizeWarnThreshold}}
 * {{getNativeTransportFrameBlockSize}}
 * {{getRepairSessionSpaceInMegabytes}}
 * {{getNativeTransportMaxFrameSize}}
Bug: Don't allocate unneeded MergeIterator in OnDiskToken#iterator 
Status: In Progress
Priority: Normal
Created: 29/Jan/20 22:24

When reviewing CASSANDRA-15392 it became apparent that the MergeIterator allocated by OnDiskToken#iterator is rarely necessary and so we should avoid allocating one when not needed and skip the MergeIterator pool when needed because its unlikely to be sized correctly.
Bug: Schema/Query analyzer
Status: Open
Priority: Normal
Created: 16/Mar/20 14:08

This proposal is to build schema/cql analyser which can help users to analyze their queries before it is too late.
  
 User may create stability issues by
 - Running expensive queries against cluster like , SELECT * or query without where clause or IN clause with many values etc.
 - Creating not so optimal schemas
 - Leaving scope for data loss or schema with performance issue (keyspace with durable writes set to false or table with many secondary indexes etc...).
  
 Most of the times these Dos & Don'ts go into some knowledge base/documentation as best practices. Having rules for best practices (which user can execute against statements) can help to avoid bad schema/queries getting executed in cluster. The main idea is to enable the users to take corrective actions, by
 1) Allowing a user to validate a DDL/DML statements before it is applied/executed.
 2) Allowing a user to validate existing schema/queries.
  
 Imo, a validation result should:
 1. Have severity
 2. Tell where it hurts like instance/replica set/cluster.
 3. Tell if it causes data loss.
 4. Tell the strategy to recover.
  
 Few approaches I can think of:
 1. Write validation rules at server side + have a new type of statement to run validations (something like MySQL's EXPLAIN) and return validation results/errors.
 2. Keep validation rules in sidecar + expose a service to run validations. In this case user can submit his statements to this API and get validation results.
 3. Expose a UI in sidecar which accepts statements and run validations. Validation rules can be with UI or UI can make either of above options.
  
 Open for any other approach.
Bug: Fix flaky test - org.apache.cassandra.index.sasi.SASIIndexTest.testMultiExpressionQueriesWhereRowSplitBetweenSSTables
Status: In Progress
Priority: Normal
Created: 04/Feb/20 23:43

{code}
[junit-timeout] Testcase: testMultiExpressionQueriesWhereRowSplitBetweenSSTables(org.apache.cassandra.index.sasi.SASIIndexTest):        FAILED
[junit-timeout] []
[junit-timeout] junit.framework.AssertionFailedError: []
[junit-timeout]         at org.apache.cassandra.index.sasi.SASIIndexTest.testMultiExpressionQueriesWhereRowSplitBetweenSSTables(SASIIndexTest.java:589)
[junit-timeout]         at org.apache.cassandra.index.sasi.SASIIndexTest.testMultiExpressionQueriesWhereRowSplitBetweenSSTables(SASIIndexTest.java:468)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.index.sasi.SASIIndexTest FAILED
{code}
Bug: Repair coordinator can hang under some cases
Status: Open
Priority: Normal
Created: 11/Feb/20 01:08

Repair coordination makes a few assumptions about message delivery which cause it to hang forever when those assumptions don’t hold true: fire and forget will not get rejected (participate has an issue and rejects the message), and a very delayed message will one day be seen (messaging can be dropped under load or when failure detector thinks a node is bad but is just GCing).

Given this and the desire to have better observability with repair (see CASSANDRA-15399), coordination should be changed into a request/response pattern (with retries) and polling (validation status and MerkleTree sending).  This would allow the coordinator to detect changes in state (it was known participate was working on validation, but it no longer knows about the validation task), and to be able to recover from ephemeral issues.
Bug: Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jan/20 15:43
Resolved: 07/Feb/20 16:26

CASSANDRA-15013 added configurable global and per endpoint limits on the number of in flight requests, measured in bytes. During times when the cluster is overloaded, it can be useful to change this setting without having to restart the Cassandra process. Changing the limits should affect all existing and new connections.
Bug: Don't shut down gossip before native transport
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 17/Feb/20 21:41
Resolved: 31/Oct/22 17:39

being shut down in wrong order causes unavailable exceptions: https://github.com/apache/cassandra/blob/da90439f0052c3a05aaf6d4268a8c719e10fafde/src/java/org/apache/cassandra/service/StorageService.java#L394

Should also do something like throw a WARN in stopGossping if rpc set to ready or native is enabled.