av9ash/GitBugs huggingface dataset:
Bug: Cassandra get range slice got Inaccurate estimates for concurrencyFactor 
Status: Open
Priority: Normal
Created: 07/May/20 10:09

Cassandra version :3.11.4
For table that  do not got a regular column , when we do partition range read and we got to the code function :

{code:java}
// Some comments here
public String getRangeSlice(PartitionRangeReadCommand command, ConsistencyLevel consistencyLevel, long queryStartNanoTime)
{code}

we will do some calculation to estimate the data per range in the function :

{code:java}
// Some comments here
private static float estimateResultsPerRange(PartitionRangeReadCommand command, Keyspace keyspace)

{code}
 when we got no index so we will use :


{code:java}
// Some comments here
command.limits().estimateTotalResults(cfs)
 --->(for CQLlimits)
*public float estimateTotalResults(ColumnFamilyStore cfs)
        {
            // TODO: we should start storing stats on the number of rows (instead of the number of cells, which
            // is what getMeanColumns returns)
            float rowsPerPartition = ((float) cfs.getMeanColumns()) / cfs.metadata.partitionColumns().regulars.size();
            return rowsPerPartition * (cfs.estimateKeys());
        }*
{code}

when the regulars is zero ,we will got an error result  that is non-zero value divided by zero .
Bug: Optimize logging with lazy log parameter evaluation
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 27/Apr/20 18:50
Resolved: 05/May/20 07:36

Multiple logging statements in the source evaluate methods and use the return values as log parameter. 
It does no harm when the log level permits for the statement. 
However, for the logs that are permitted, the evaluation is a wastes of CPU. 
The log parameters are not needed, but still being evaluated!
For such cases, lazy evaluation (by leveraging lambda) can be introduced to skip competing the string parameter.
Bug: Internode messaging connection setup between 4.0 and legacy SSL 3.0 fails if initial connection version incorrect
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Apr/20 03:06
Resolved: 13/May/20 15:36

This was discovered while testing upgrading an SSL enabled cluster from 3.0 to 4.0.  The 3.0 cluster was configured to only listen on the ssl storage port. When the upgraded 4.0 node started it received a gossip messsage that triggered a shadow round before it had correctly set the messaging versions for the other endpoints.

Sending the message created the connection, but because the endpoint defaulted to {{VERSION_40}} the initial connect attempt was to the regular {{storage_port}}.  The 3.0 node was only listening on the {{ssl_storage_port}}, so the connection was refused and the {{OutboundConnection.onFailure}} handler was called.  As the shadow
gossip round had queued up a message, the {{hasPending}} branch was followed and the connection was rescheduled, however the port is never recalculated as the original settings are used so it always fails.

Meanwhile, the node discovered information about peers through inbound connection and gossip updating the messaging version for the endpoint which could have been used to make a valid connection.
Bug: Upgrade-dtests on trunk not working in CircleCI
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/May/20 13:51
Resolved: 04/Jun/20 08:45

~3600 Upgrade-dtests are failing in CircleCI for trunk due to the missing {{JAVA8_HOME}} environment variable.

Patching the Docker image is rather simple by creating a new image:
{code}
FROM nastra/cassandra-testing-ubuntu1910-java11-w-dependencies:20200406
ENV JAVA8_HOME=/usr/lib/jvm/java-8-openjdk-amd64
{code}

Pushed the above to Docker hub as [snazy/cassandra-testing-ubuntu1910-java11-w-dependencies:202005261540|https://hub.docker.com/layers/snazy/cassandra-testing-ubuntu1910-java11-w-dependencies/202005261540/images/sha256-ac8a713be58694f095c491921e006c2d1a7823a3c23299e477198e2c93a6bbd7?context=explore]

The size of the whole Docker image is a little concerning though (1.85G compressed), but that's out of the scope of this ticket.

I'll prepare a patch soon-ish.
Bug: Make Table/Keyspace Metric Names Consistent With Each Other
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jun/20 14:19
Resolved: 09/Sep/20 18:36

As part of CASSANDRA-15821 it became apparent that certain metric names found in keyspace and tables had different names but were in fact the same metric - they are as follows:

* Table.SyncTime == Keyspace.RepairSyncTime
* Table.RepairedDataTrackingOverreadRows == Keyspace.RepairedOverreadRows
* Table.RepairedDataTrackingOverreadTime == Keyspace.RepairedOverreadTime
* Table.AllMemtablesHeapSize == Keyspace.AllMemtablesOnHeapDataSize
* Table.AllMemtablesOffHeapSize == Keyspace.AllMemtablesOffHeapDataSize
* Table.MemtableOnHeapSize == Keyspace.MemtableOnHeapDataSize
* Table.MemtableOffHeapSize == Keyspace.MemtableOffHeapDataSize

Also, client metrics are the only metrics to start with a lower case letter. Change those to upper case to match all the other metrics.

Unifying this naming would help make metrics more consistent as part of CASSANDRA-15582
Bug: Jenkins Test Results Report in plaintext for ASF ML
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Apr/20 10:35
Resolved: 06/May/20 11:15

The Jenkins pipeline builds now aggregate all test reports.

For example: 
- https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/
- https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests

But Jenkins can only keep a limited amount of build history, so those links are not permanent, can't be used as references, and don't help for bisecting and blame on regressions (and flakey tests) over a longer period of time.

The builds@ ML can provide a permanent record of test results. 

This was first brought up in these two threads: 
- https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E
- https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E

An example plaintext report, to demonstrate feasibility, is available here: https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E

Hurdles:
 - the ASF mailing lists won't accept html, attachments, or any message body over 1MB.
 - packages are used as a differentiator in the final aggregated report. The cqlsh and dtests currently don't specify it. It needs to be added as a "dot-separated" prefix to the testsuite and testcase name.
Bug: Debian package fails to download on Arm-based hosts
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jun/20 17:17
Resolved: 20/Jan/21 21:16

Following the first three steps of the [Debian install process|https://cassandra.apache.org/download/], after an apt-get update you'll see this line:
{code:bash}
$ sudo apt-get update
...
N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://downloads.apache.org/cassandra/debian 311x InRelease' doesn't support architecture 'arm64'
{code}

Checking the [Debian repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there is no aarch64 variant available.

Should you then attempt to install Cassandra:
{code:bash}
$ sudo apt-get install cassandra
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package cassandra is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'cassandra' has no installation candidate
{code}

Note that there is a workaround available: if you specify "amd64" as the arch for the source, it downloads and runs on Arm without issue:
{code:bash}
echo "deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
{code}

The Redhat RPM contains a "noarch" arch type, so it will download on any host. (Cassandra does not use separate binaries/releases for different architectures, so this seems to be the correct approach, but adding an aarch64 variant would also suffice.)
Bug: Remove jackson-mapper-asl-1.9.13 to address CVE
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/May/20 22:49
Resolved: 18/Aug/20 11:16

Recent scan results identified the following CVE that require this upgrade to address

[https://nvd.nist.gov/vuln/detail/CVE-2019-10172]
Bug: Flaky test: testNoTreesRetainedAfterDifference - org.apache.cassandra.repair.RepairJobTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jun/20 14:56
Resolved: 22/Jun/20 16:37

link: [https://circleci.com/gh/maedhroz/cassandra/21#tests/containers/95]
Bug: replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc failure
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Jun/20 07:21
Resolved: 24/Jun/20 18:22

replication_test.TestSnitchConfigurationUpdate.test_rf_expand_gossiping_property_file_snitch_multi_dc has been failing for a [while|https://ci-cassandra.apache.org/job/Cassandra-trunk/176/testReport/dtest-large.replication_test/TestSnitchConfigurationUpdate/test_rf_expand_gossiping_property_file_snitch_multi_dc/history/]. Also fails locally
Bug: Include DROPPED_COLUMNS in schema digest computation.
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Jun/20 19:20
Resolved: 02/Jun/20 18:02

CASSANDRA-11050 introduced dropped columns but excluded it from schema digest computations, with a comment to include the table in the next major release - 4.0.

Change SchemaKeyspace to include DROPPED_COLUMNS in the schema digest computation.
Bug: Bootstrap resume and TestReplaceAddress fixes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jun/20 15:37
Resolved: 16/Jun/20 17:45

This has been [broken|https://ci-cassandra.apache.org/job/Cassandra-trunk/159/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_restart_failed_replace/history/] for ages
Bug: Dropping a column can break queries until the schema is fully propagated
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jun/20 07:50
Resolved: 06/Oct/20 17:16

With a table like:
{code}
CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
{code}

and we drop {{v2}}, we get this exception on the replicas which haven't seen the schema change:
{code}
ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107 AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread Thread[SharedPool-Worker-1,5,node2]
java.lang.IllegalStateException: [ColumnDefinition{name=v1, type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}, ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}, ColumnDefinition{name=v3, type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}] is not a subset of [v1 v3]
	at org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546) ~[main/:na]
	at org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478) ~[main/:na]
	at org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184) ~[main/:na]
	at org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114) ~[main/:na]
	at org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102) ~[main/:na]
	at org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132) ~[main/:na]
	at org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87) ~[main/:na]
...
{code}

Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
Bug: Use "allow list" or "safe list" instead of the term "whitelist" 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/20 20:41
Resolved: 12/Jun/20 10:40

Language matters. I'd like to remove all references in Apache Airflow to whitelist or black list, and the Cassandra Python API has some that we can't easily remove.

The recent global events have made this even more relevant, but this has been on my radar for a while now. Here is a well written article for why I think it matters 

https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white

{quote}It's fairly common to say whitelisting and blacklisting to describe desirable and undesirable things in cyber security.

However, there's an issue with the terminology. It only makes sense if you equate white with 'good, permitted, safe' and black with 'bad, dangerous, forbidden'. There are some obvious problems with this. {quote}

My exposure to is via the Python API where there is the cassandra.pollicies.WhiteListRoundRobinPolicy class. I propose that this be renamed to AllowListRoundRobinPolicy instead. I do not know if there are other references.
Bug: MemoryOutputStream overflow on large bloom filter
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Jun/20 10:16
Resolved: 12/Jun/20 14:17

Since CASSANDRA-9067, Cassandra will use {{MemoryOutputStream}} to reconstruct BF Memory without re-ordering bytes, see {{OffsetBitSet#deserialize}}. But {{MemoryOutputStream}} use {{INT}} to track position and will overflow when BF size exceeds 2GB.
{code:java|title=stacktrace}
error: Illegal bounds [-2147483648..-2147483584); size: 4588588016
-- StackTrace --
java.lang.AssertionError: Illegal bounds [-2147483648..-2147483584); size: 4588588016
	at org.apache.cassandra.io.util.Memory.checkBounds(Memory.java:185)
	at org.apache.cassandra.io.util.Memory.setBytes(Memory.java:138)
	at org.apache.cassandra.io.util.MemoryOutputStream.write(MemoryOutputStream.java:45)
{code}
Bug: Memory leak in CompressedChunkReader
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jun/20 09:04
Resolved: 02/Oct/20 15:26

CompressedChunkReader uses java.lang.ThreadLocal to reuse ByteBuffer for compressed data. ByteBuffers leak due to peculiar ThreadLocal quality.
ThreadLocals are stored in a map, where the key is a weak reference to a ThreadLocal and the value is the user's object (ByteBuffer in this case). When a last strong reference to a ThreadLocal is lost, weak reference to ThreadLocal (key) is removed but the value (ByteBuffer) is kept until cleaned by ThreadLocal heuristic expunge mechanism. See ThreadLocal's "stale entries" for details.

When a number of long-living threads is high enough this results in thousands of ByteBuffers stored as stale entries in ThreadLocals. In a not-so-lucky scenario we get OutOfMemoryException.
Bug: Introduce MIDRES config in CircleCI
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Apr/20 15:14
Resolved: 09/Jun/20 17:16

From document: [https://gist.github.com/newkek/bb79dccbe7d2f5e41b2a3daac3858fde]

We have identified that the current HIGHRES configuration seems to require resources that might not bring the best cost efficiency to the build.

We have also identified several "good compromise" configurations that allow to get decent performance out of the test suites, without going all out on the big config.

It seems it would be useful for a lot of people to have this available as a {{config.yml.MIDRES}} configuration in the {{.circleci}} folder. This way we do not need to argue on modifying the {{HIGHRES}} configuration so as to not impact the people already using it, but can still have easy access the "compromise" config.
Bug: Queries on KEYS 2i are broken by DROP COMPACT STORAGE on 3.0
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Jun/20 15:14
Resolved: 23/Jul/20 23:19

From 3.0 onwards, the declared columns of a thrift table are internally static columns. While the table is compact, this 

After DROP COMPACT STORAGE is used on a table that has a KEYS 2i, queries that uses that index will start failing with:
{noformat}
Queries using 2ndary indexes don't support selecting only static columns
{noformat}

In 3.0, we don't support index on static columns and have that validation that rejects 2i queries on static columns. But the declared columns of compact table are static under the hood, and while this specific validation is skipped while the table is compact, it isn't anymore after the DROP COMPACT STORAGE.

Note that internally, nothing changes with the DROP COMPACT STORAGE, and the 2i queries would still work as well as before, it is just that they are rejected.

Also not that this is only a problem in 3.0. In 3.11, static column indexes were added (CASSANDRA-8103) and thus this validation has been removed, and everything works as it should.

However, since DROP COMPACT STORAGE is a mandatory step for compact tables before upgrading to 4.0, fixing this annoying in 3.0 would avoid forcing users with KEYS 2i on 3.0 to upgrade to 3.11 before going to 4.0.
Bug: Unresolvable false digest mismatch during upgrade due to CASSANDRA-10657
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/May/20 08:51
Resolved: 28/Sep/20 15:23

CASSANDRA-10657 introduced changes in how the ColumnFilter is interpreted. This results in digest mismatch when querying incomplete set of columns from a table with consistency that requires reaching instances running pre CASSANDRA-10657 from nodes that include CASSANDRA-10657 (it was introduced in Cassandra 3.4). 

The fix is to bring back the previous behaviour until there are no instances running pre CASSANDRA-10657 version.
Bug: Add tests to cover CacheMetrics
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/May/20 14:11
Resolved: 19/Aug/20 14:54

{{CacheMetrics}} and {{ChunkCacheMetrics}} do not have unit tests covering them.  {{CachingBench}} seems to provide some coverage but those tests (which don't appear to run as part of the standard run of unit tests) are failing and do not assert against all defined metrics, nor do they seem to assert code in {{InstrumentingCache}} which also incremented metrics.
Bug: Frozen RawTuple is not annotated with frozen in the toString method
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jun/20 20:40
Resolved: 22/Jul/20 09:16

All raw types (e.g. RawCollection, RawUT) that supports freezing wraps the type name with 'frozen<>' in the toString method, except RawTuple.

Therefore, the RawTuple::toString output misses the frozen wrapper.

Tuple is always frozen. However since CASSANDRA-15035, it throws when the inner tuple is not explicitly wrapped with frozen within a collection.

The method, CQL3Type.Raw::toString, is referenced at multiple places in the source. For example, referenced in CreateTypeStatement.Raw and involved in CQLSSTableWriter. Another example is that it is called to produce the SchemaChange at several AlterSchemaStatement implementations.

A test can prove that missing the frozen wrapper causes exception when building CQLSSTableWriter for user types defined like below. Note that the inner tuple is wrapped with frozen in the initial CQL statement.
{code:java}
CREATE TYPE ks.fooType ( f list<frozen<tuple<text, text>>> )
{code}
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Non-frozen tuples are not allowed inside collections: list<tuple<text, text>>
	at org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.throwNestedNonFrozenError(CQL3Type.java:710)
	at org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepare(CQL3Type.java:669)
	at org.apache.cassandra.cql3.CQL3Type$Raw$RawCollection.prepareInternal(CQL3Type.java:661)
	at org.apache.cassandra.schema.Types$RawBuilder$RawUDT.lambda$prepare$1(Types.java:341)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
	at org.apache.cassandra.schema.Types$RawBuilder$RawUDT.prepare(Types.java:342)
	at org.apache.cassandra.schema.Types$RawBuilder.build(Types.java:291)
	at org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.createTypes(CQLSSTableWriter.java:551)
	at org.apache.cassandra.io.sstable.CQLSSTableWriter$Builder.build(CQLSSTableWriter.java:527)
{code}
Bug: Generating nodetool docs fails with python 3
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Apr/20 10:13
Resolved: 23/Jul/20 22:19

Building nodetool docs with the ant target 'gen-doc' fails for python 3. Python 3 doesn't allow the file open mode "rw+".
{noformat}
gen-doc:
     [exec] python convert_yaml_to_rst.py ../conf/cassandra.yaml source/configuration/cassandra_config_file.rst
     [exec] python gen-nodetool-docs.py
     [exec] Makefile:64: recipe for target 'html' failed
     [exec] Traceback (most recent call last):
     [exec]   File "gen-nodetool-docs.py", line 75, in <module>
     [exec]     with open(helpfilename, "rw+") as helpfile:
     [exec] ValueError: must have exactly one of create/read/write/append mode
     [exec] make: *** [html] Error 1
     [exec] Result: 2
{noformat}
Fails on and patch [^0001-Fix-file-open-modes-for-python-3.patch] tested on the following platforms: Ubuntu 18.04.4 LTS with Python 3.6.9 and FreeBSD 12.1-RELEASE-p1 with Python 3.7.7.
Bug: Add a startup check to detect if LZ4 uses java rather than native implementation
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Jun/20 00:44
Resolved: 19/Jun/20 13:25

In some environments the native implementation can’t link with glibc and silently falls back to java; this hurts performance.  To help warn the operators, we should add a startup check to detect this.
Bug: cqlsh not able to fetch all rows when in batch mode
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Jun/20 00:56
Resolved: 30/Jun/20 23:00

The cqlsh in trunk only display the first page when running in the batch mode, i.e. using {{--execute}} or {{--file}} option. 
  
 It is a change of behavior. In 3.x branches, the cqlsh returns all rows. 
  
 It can be reproduced in 3 steps.
{code:java}
 1. ccm create trunk -v git:trunk -n1 && ccm start
 2. tools/bin/cassandra-stress write n=1k -schema keyspace="keyspace1"   // write 1000 rows
 3. bin/cqlsh -e "SELECT * FROM keyspace1.standard1;"                    // fetch all rows
{code}
 
 There are 1000 rows written. But the output in step 3 will only list 100 rows, which is the first page. 
{code:java}
➜ bin/cqlsh -e "SELECT * FROM keyspace1.standard1" | wc -l
     105{code}
 
 The related change was introduced in https://issues.apache.org/jira/browse/CASSANDRA-11534, where the cqlsh.py script no longer fetch all rows when not using tty in the print_result method.
Bug: Range read concurrency factor didn't consider range merger
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Apr/20 16:04
Resolved: 22/Jun/20 15:29

During range read, coordinator computes concurrency factor which is the number of vnode ranges to contact in parallel for the next batch.

But in {{RangeCommandIterator}}, vnode ranges are merged by {{RangeMerger}} if vnode ranges share enough replicas to satisfy consistency level. eg. vnode range [a,b) has replica n1,n2,n3 and vnode range [b,c) has replica n2,n3,n4, so they can be merged as range [a,c) with replica n2, n3 for Quorum.

Currently it counts number of merged ranges towards concurrency factor. Coordinator may fetch more ranges than needed.

----

Another issue is that when executing range read on table with very small amount of data, concurrency factor can be bumped to {{size of total vnode ranges}}, eg. 10k, depending on the num of vnodes and cluster size. As a result, coordinator will send large number of concurrent range requests, potentially slowing down the cluster.. We should cap the max concurrency factor..