av9ash/GitBugs huggingface dataset:
Bug: ssl-factory demo in examples is broken
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Feb/23 16:10
Resolved: 08/May/23 20:32

this fails, it is not happening in cassandra-4.1

{code}
cd examples/ssl-factory
ant build && ant test
{code}

My suspicion is that SSL factory related stuff was recently changed, in trunk, by (1) and this broke related ssl test.

[~maulin.vasavada] do you have some time to look into that as you are the author of the tests? I think I fixed the most of it here (2) but one test is still failing and I can not wrap my head around that one. It gives:

{code}
    [junit] Testcase: buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):        Caused an ERROR
    [junit] Failed to build key manager store for secure connections
    [junit] javax.net.ssl.SSLException: Failed to build key manager store for secure connections
    [junit]     at org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
    [junit]     at org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
    [junit]     at org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
    [junit]     at org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
    [junit] Caused by: java.io.IOException: overrun, bytes = 1195
    [junit]     at javax.crypto.EncryptedPrivateKeyInfo.<init>(EncryptedPrivateKeyInfo.java:95)
    [junit]     at org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
    [junit]     at org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
    [junit]     at org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
{code}

(1) https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
(2) https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup

cc [~Jyothsnakonisa]
Bug: Cqlsh incorrectly formats duration
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Jan/23 12:34
Resolved: 17/Jan/23 20:35

It looks like something broke between C* 3.11 and C* 4.X when it comes to duration types.

Example:

CREATE KEYSPACE users WITH replication = \{'class': 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
CREATE TABLE users.user_credentials_by_email (email text,la_duration duration,PRIMARY KEY(email));
INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES ( 'test0@test.com', 12h);
INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES ( 'test1@test.com', 12h30m);
INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES ( 'test2@test.com', 12h30m30s);
INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES ( 'test3@test.com', 12h30m30s250ms);
INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES ( 'test4@test.com', PT12H30M);

3.11:

cassandra@cqlsh> SHOW VERSION ;
[cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol v4]
cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;

 email          | la_duration
----------------+----------------
 test0@test.com |            12h
 test3@test.com | 12h30m30s250ms
 test4@test.com |         12h30m
 test1@test.com |         12h30m
 test2@test.com |      12h30m30s

(5 rows)

4.X:

cassandra@cqlsh> SHOW VERSION ;
[cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;

 email          | la_duration
----------------+-----------------------------------------------------
 test0@test.com |                                               12.0h
 test3@test.com | 12.508402777777778h30.504166666666666m30.25s250.0ms
 test4@test.com |                                          12.5h30.0m
 test1@test.com |                                          12.5h30.0m
 test2@test.com |                       12.508333333333333h30.5m30.0s

(5 rows)
Bug: Nodetool documentation not working
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Jan/23 23:39
Resolved: 30/Jan/23 21:51

Clicking on the nodetool in the Tool branch of the doco tree doesn't do anything.

Also, links found in Google search (eg [https://cassandra.apache.org/doc/latest/cassandra/tools/nodetool/tablehistograms.html)] result in "Not Found" error.
Bug: CEP-15: (Accord) Migrate Accord away from JDK random to a new interface RandomSource
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jan/23 22:19
Resolved: 15/Mar/23 20:31

JDK Random has basic functions needed, but is lacking and requires custom utils to add some added methods desired (such as next[short,int,long,float,double] in a range), so to deal with this we should own the random interface we use.

This has 2 main context points for accord: Node (breaking API change), and BurnTest.

By owning our own interface, we could also have C* Simulator’s RandomSource “extend” it so we don’t have to redefine everything cross both repos.
Bug: Rename internal state() method in AbstractFuture to not conflict with Java 19 changes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Mar/23 09:27
Resolved: 10/Apr/23 18:03

From Java 19 we have new method Future.state and it conflicts with our private method. Fix bellow. 

[https://download.java.net/java/early_access/jdk20/docs/api/java.base/java/util/concurrent/Future.html#state()]

 
{code:java}
+++ b/src/java/org/apache/cassandra/utils/concurrent/AbstractFuture.java
@@ -494,11 +494,11 @@ public abstract class AbstractFuture<V> implements Future<V>
     public String toString()
     {
         String description = description();
-        String state = state();
+        String state = stateInfo();
         return description == null ? state : (state + ' ' + description);
     }
 
-    private String state()
+    private String stateInfo()
     {
         Object result = this.result;
         if (isSuccess(result)){code}
Bug: "AttributeError: module 'py' has no attribute 'io'" reported in multiple tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Jan/23 15:52
Resolved: 14/Feb/23 21:35

{{title = 'Timeout'}}
{{stream = <_io.TextIOWrapper name='<stderr>' mode='w' encoding='utf-8'>}}
{{{}sep = '+'{}}}{{{}def write_title(title, stream=None, sep="~"):{}}}
{{{}"""Write a section title.{}}}{{{}If *stream* is None sys.stderr will be used, *sep* is used to{}}}
{{draw the line.}}
{{"""}}
{{if stream is None:}}
{{stream = sys.stderr}}
{{> width = py.io.get_terminal_width()}}
{{E AttributeError: module 'py' has no attribute 'io}}

 

is reported in multiple tests as noted below.

possibly a class loader issue associated with CASSANDRA-18150

4.1
[https://ci-cassandra.apache.org/job/Cassandra-4.1/256/testReport/dtest-offheap.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_full_repairs_lcs]

3.11
[https://ci-cassandra.apache.org/job/Cassandra-3.11/424/testReport/dtest.bootstrap_test/TestBootstrap/test_simultaneous_bootstrap/]

3.0
[https://ci-cassandra.apache.org/job/Cassandra-3.0/328/testReport/dtest-upgrade.upgrade_tests.upgrade_supercolumns_test/TestSCUpgrade/test_upgrade_super_columns_through_all_versions/]
Bug: Reduce memory allocations of calls to ByteBufer.duplicate() made in org.apache.cassandra.transport.CBUtil#writeValue
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jan/23 21:06
Resolved: 06/Mar/23 20:05

Currently, org.apache.cassandra.transport.CBUtil#writeValue(java.nio.ByteBuffer, io.netty.buffer.ByteBuf) calls ByteBufer.duplicate() and is found to be 20% of memory allocations in production. No changes have been made to reduce this but there is discussion related to the issue in CASSANDRA-13741. Attached below are the performance result for disk based queries and mostly memory based queries.
Bug: Dtests marked with @ported_to_in_jvm can be skipped since 4.1
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Mar/23 12:26
Resolved: 19/Apr/23 10:35

During the CASSANDRA-15536 epic we ported multiple Python dtests to in-JVM dtests.

The ported Python dtests are still present but marked with a new {{@ported_to_in_jvm}} annotation. JVM dtests didn't support vnodes at that time, so when a Python dtest is marked with that annotation it's only run for vnodes config, whereas it's skipped if vnodes are off.

However, we have had support for vnodes on JVM dtests since 4.1. Thus, I think we should modify the {{@ported_to_in_jvm}} annotation to also skip configs with vnodes if all the nodes are in 4.1 or later.
Bug: Add max_sstable_size and max_sstable_duration metrics virtual tables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Mar/23 20:44
Resolved: 15/Mar/23 20:40

We added max_sstable_size and max_sstable_duration metrics in CASSANDRA-18283 however there are not system_views vtables for these metrics yet.
Bug: ECJ upgrade
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jan/23 22:03
Resolved: 25/Jul/23 01:55

During testing it was identified that we will need to update ECJ for the Java UDF functions in order to bring Java 17 in.

It seems the compiler artifacts are moved from [here|https://mvnrepository.com/artifact/org.eclipse.jdt.core.compiler/ecj] to [here|https://mvnrepository.com/artifact/org.eclipse.jdt/ecj] and there is change of license from EPL1.0 to EPL2.0 too. But if I read correctly [here|https://www.apache.org/legal/resolved.html#weak-copyleft-licenses] that should not affect us

Further testing and review of all changes between artifacts to be done.
ECJ is used for the eclipse-warnings and Java UDFs

As agreed on the [dev mailing list|https://lists.apache.org/thread/8ok01odwx79crxw45cnfh0n1j4nsf9cp] we will replace eclipse-warnings in trunk with CheckerFramework equivalent one but better.

So as part of this ticket we are removing ant eclipse-warnings task and upgrading ecj for Java UDFs.
Bug: Add test conf for JDK17
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Feb/23 21:34
Resolved: 27/Feb/23 17:19

Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current trunk with JDK17 but in order to start Cassandra and test it we will need also our conf files updated with some preliminary conf for test purposes.

This ticket will be used to add those to current trunk
Bug: Add details to Error message: Not enough space for compaction 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Feb/23 17:30
Resolved: 04/May/23 10:52

When compaction fails, the log message should list a) the free space available on disk at that point in time and b) perhaps the number and/or size of the source sstables being compacted.

Free space can change from one moment to the next, so when the below compaction failed because it needed 161GB, upon checking the server a few minutes later, it had 184GB free.  Similarly, the error message mentions it was writing out one SSTable on this STCS table, but its not clear if it was combining X -> 1 tables, or something else.
{noformat}
[INFO ] [CompactionExecutor:77758] cluster_id=87 ip_address=127.1.1.1  CompactionTask.java:241 - Compacted (8a1cffe0-abb5-11ed-b3fc-8d2ac2c52f0d) 1 sstables to [...] to level=0.  86.997GiB to 86.997GiB (~99% of original) in 1,508,155ms.  Read Throughput = 59.069MiB/s, Write Throughput = 59.069MiB/s, Row Throughput = ~20,283/s.  21,375 total partitions merged to 21,375.  Partition merge counts were \{1:21375, }

[ERROR] [CompactionExecutor:77774] cluster_id=87 ip_address=127.1.1.1  CassandraDaemon.java:581 - Exception in thread Thread[CompactionExecutor:77774,1,main]
java.lang.RuntimeException: Not enough space for compaction, estimated sstables = 1, expected write size = 161228934093
    at org.apache.cassandra.db.compaction.CompactionTask.buildCompactionCandidatesForAvailableDiskSpace(CompactionTask.java:386)
    at org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:126)
    at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
    at org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:77)
    at org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:100)
    at org.apache.cassandra.db.compaction.CompactionManager$7.execute(CompactionManager.java:613)
    at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:377)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
Bug: Remove obsolete 'six' package reintroduced by a merge
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Mar/23 23:15
Resolved: 22/Mar/23 15:24

The 4.1.x and trunk commits for CASSANDRA-18088 inadvertently re-introduced 'six' and obsolete python 2.7 conditional checks and should be removed.

I.e., SaferScanner = Py36SaferScanner if six.PY3 else Py2SaferScanner – but there is no Py2SaferScanner anymore.
Bug: commons-cli vulnerability: CVE-2021-37533
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jan/23 20:47
Resolved: 17/Jan/23 16:02

This CVE is being reported by the OWASP scan for:

commons-cli-1.1.jar: CVE-2021-37533
commons-codec-1.9.jar: CVE-2021-37533
commons-math3-3.2.jar: CVE-2021-37533

additionally commons-lang3-3.1.jar is also reported on 3.x.
Bug: PaxosPrepare may add instances to the Electorate that are not in gossip
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jan/23 20:20
Resolved: 27/Jan/23 20:39

org.apache.cassandra.service.paxos.PaxosPrepare.RequestHandler#execute is given a list of electorate from the peer and attempts to compute its own, then replies back with this set.

On the peer side, we then have the set we sent and the set from the other instance... we then fetch the EndpointState from Gossiper and store into a Map, a map we later attempt to inject into Gossip.

It is possible that Gossiper does not know about the instance yet, so returns a null; causing a NullPointerException in downstream code.
Bug: Cqlsh command "COPY … TO STDOUT" fails with "… object is not callable"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Mar/23 20:21
Resolved: 22/Mar/23 18:31

Since 4.1.0, cqlsh fails on COPY commands with standard output as target. 

Steps to reproduce:
{noformat}
$> docker run -d --name cassandra --rm cassandra:4.1.1
$> docker exec cassandra cqlsh -e 'COPY system.local(cluster_name) TO STDOUT'
  <stdin>:1:'NoneType' object is not callable
{noformat}

Possibly a regression introduced by this commit [6341319|https://github.com/apache/cassandra/commit/634131961af9c1d88b34797c1c45000f71a76dae#diff-584645e6e932edd7a17f03c79ae87b1f1f8ed54919a31ce8785af156b89c0b76L260].

Also, it looks like it has happened before: CASSANDRA-12497
Bug: rat targets do not adhere to build.dir property
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Jan/23 12:12
Resolved: 23/Jan/23 14:35

I detected this when I was trying to put my build dir to ramdisk. I have plenty of RAM available on my workstation (64GB) and I was thinking about moving "build" dir to ramdisk so I could make it faster a little bit and also spare some write cycles to ssd. It can look like irrelevant improvement but I think that if devs are building the project repeatedly times and times again, this can easily add up.
{code:java}
mkdir /tmp/cassandra
# in /etc/fstab
tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777 0 0
# then sudo mount -a
# I have worktree setup so the build for each branch will end up in different dir:
# mkdir -p /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
{code}
Then in build.properties for each respective branch:
{code:java}
ant.gen-doc.skip: true
build.dir: /tmp/cassandra/trunk/build
build.dir.lib: /tmp/cassandra/trunk/build/lib
{code}
The problem with this is that it fails on rat, because there is not "build.dir" property used, it is hardcoded to "build" but there is not anything to rat on so it will hang.

To have the very same experience, I am also creating a symlink 
 
{code}
ln -s /tmp/cassandra/trunk/build build
{code}

so "cd build / ls build" in the root of the repository will take me to ramdisk. The problem with this is that there is "build/" in .gitignore but not "build" (as file) so the repository is in dirty state. I suggest to add "build" to .gitignore as part of this PR as that is just an opportunistic fix really.
Bug: Add support for Paxos repair to PaxosV1
Status: Triage Needed
Priority: Normal
Created: 03/Jan/23 22:05

PaxosV2 supports repair of Paxos state by maintaining a 2i that leverages PaxosUncommittedTracker to track uncommitted transactions in the system paxos table. This could be enabled for PaxosV1 to aid with migration.

Alternatively this could be a scan of the system paxos table and then repair of uncommitted transactions that are found.

Need to find the right way from A to B here. [~benedict]
Bug: Investigate initial size of GrowableByteArrayDataOutput in RAMIndexOutput
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 23/Feb/23 09:36
Resolved: 07/Sep/23 15:56

The GrowableByteArrayDataOutput in RAMIndexOutput is currently initialized with a size of 128 bytes. There is no explanation as to why this size was chosen. 

The GrowableByteArrayDataOutput does not lazily allocate memory but only ever allocates enough for each write operation. This can lead to a lot of fresh allocations and calls to System.arrayCopy. 

Since RAMIndexOutput is used to build the on-disk postings in SAI it is likely that the size of the in-memory array is going to grow considerably more that 128 bytes.

We should investigate changing this initial value to something higher and possibly changing the GrowableByteArrayDataOutput class to allocate in blocks rather than write increments.
Bug: Test failure: org.apache.cassandra.distributed.test.FailingRepairTest - testFailingMessage[VALIDATION_REQ/parallel/true]
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Mar/23 19:45
Resolved: 04/Sep/23 08:32

First seen [here|https://app.circleci.com/pipelines/github/driftx/cassandra/928/workflows/f4e93a72-d4aa-47a2-996f-aa3fb018d848/jobs/16206] this test times out for me consistently on both j8 and j11 where 4.1 and trunk do not.
Bug: dtest-offheap.repair_tests.repair_test.TestRepair.test_thread_count_repair
Status: Open
Priority: Normal
Created: 16/Feb/23 08:43

https://ci-cassandra.apache.org/job/Cassandra-4.0/530/testReport/dtest-offheap.repair_tests.repair_test/TestRepair/test_thread_count_repair/
Bug: Test Failure: repair_tests.repair_test.TestRepair.test_*dc_repair
Status: Open
Priority: Normal
Created: 15/Jan/23 09:55

Flaky.
{noformat}
Unexpected error found in node logs (see stdout for full details). Errors: [[node3] 'ERROR [MemtableReclaimMemory:1] 2023-01-13 04:23:38,762 CassandraDaemon.java:581 - Exception in thread Thread[MemtableReclaimMemory:1,5,main]java.lang.AssertionError: null
at org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
at org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
at org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
at org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
at org.apache.cassandra.utils.memory.NativeAllocator.setDiscarded(NativeAllocator.java:203)
at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:212)
at org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:750)']
{noformat}
Bug: Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck
Status: Open
Priority: Normal
Created: 15/Jan/23 09:37

Flakey.

{noformat}
java.lang.RuntimeException: org.apache.cassandra.exceptions.UnavailableException: Cannot achieve consistency level ALL
	at org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:218)
	at org.apache.cassandra.distributed.impl.Coordinator.executeWithTracing(Coordinator.java:125)
	at org.apache.cassandra.distributed.test.ReadDigestConsistencyTest.checkTraceForDigestMismatch(ReadDigestConsistencyTest.java:63)
	at org.apache.cassandra.distributed.test.ReadDigestConsistencyTest.testDigestConsistency(ReadDigestConsistencyTest.java:105)
	at org.apache.cassandra.distributed.upgrade.MixedModeReadTest.lambda$mixedModeReadColumnSubsetDigestCheck$2(MixedModeReadTest.java:60)
	at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:222)
	at org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck(MixedModeReadTest.java:63)
Caused by: org.apache.cassandra.exceptions.UnavailableException: Cannot achieve consistency level ALL
	at org.apache.cassandra.db.ConsistencyLevel.assureSufficientLiveNodes(ConsistencyLevel.java:334)
	at org.apache.cassandra.service.AbstractReadExecutor.getReadExecutor(AbstractReadExecutor.java:162)
	at org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.<init>(StorageProxy.java:1897)
	at org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1859)
	at org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1802)
	at org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1707)
	at org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:1221)
	at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:315)
	at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:285)
	at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:117)
	at org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:106)
	at org.apache.cassandra.distributed.impl.Coordinator.lambda$asyncExecuteWithTracingWithResult$1(Coordinator.java:77)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
	at java.lang.Thread.run(Thread.java:750)
{noformat}