av9ash/GitBugs huggingface dataset:
Bug: Block/Warn creating keyspace with RF > Cassandra node count
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jun/21 13:28
Resolved: 17/Mar/22 12:10

 

Using Cassandra 3.11.10, 3 nodes cluster Cassandra allows to create a keyspace having `replication_factor` greater than the number of available nodes.

 
{code:java}
-- successfully created Keyspace with RF = 3 > node count = 3

CREATE KEYSPACE mykeyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 5 };
{code}
From [this discussion|https://community.datastax.com/questions/11623/create-keyspace-with-rf-physical-cassandra-node-co.html] on community.datastax.com. It appears that this would lead to serious operational problems.

Would it be OK to improve the `CREATE KEYSPACE` to block (or display warning) when attempting to set `replication_factor` > node count?
Bug: ALTER ... ADD can increase the number of SSTables being read
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Jun/21 13:20
Resolved: 01/Jul/21 12:17

With the following SSTables:
{code:java}
CREATE TABLE my_table (pk int, ck int, v1 int, PRIMARY KEY(pk, ck))

INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 1) USING TIMESTAMP 1000;
--> flush()
INSERT INTO my_table (pk, ck, v1) VALUES (1, 1, 2) USING TIMESTAMP 2000;
--> flush()
INSERT INTO my_table  (pk, ck, v1) VALUES (1, 1, 3) USING TIMESTAMP 3000
--> flush()
{code}
the following query:
{code:java}
SELECT pk, ck, v1 FROM my_table WHERE pk = 1 AND ck = 1{code}
will only read the third SSTable.

If we add a column to the table (e.g. {{ALTER TABLE my_table ADD v2 int}}) and rerun the query, the query will read the 3 SSTables.

The reason for this behavior is due to the fact that C* is trying to read all the {{fetched}} columns to ensure that it will return a row if at least one of its column is non null.

In practice for CQL tables, C* does not need to fetch all columns if the row contains a primary key liveness as it is enough to guaranty that the row exists. By consequence, even after the addition of the new column C* should read only the third SSTable.
Bug: Harden internode message resource limit accounting against serialization failures
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Apr/21 21:26
Resolved: 20/Apr/21 17:27

If the internode messaging exception recovery code fails and is unable to correctly adjust the resource limits for an OutboundConnection, it affects the other connection types sharing the same OutboundConnections so that any of the connections could hit {{assert using >= 0;}} in
{{org.apache.cassandra.net.ResourceLimits.Concurrent#release}}.

While it is possible to modify all of the outbound connection code to re-initialize all of the connections with a correct limit, the effort to test and maintain the recovery code seems too high for something that should "never happen" (except it did once, which is why it needs hardening).  The safer option is to kill the JVM and have whatever external monitoring is in place restart the instance in a known good state.

Additionally, the logging for dropping outbound messages that have expired or are unserializable messages takes place after the recovery handling logic. If there are problems with the recovery logic that throw an exception, the message is never logged for future diagnosis. Logging should take place first, and then releasing capacity/handling the expiration/serialization.

Discovered on a branch modified for testing that threw an exception in the Verb.serializeSize method.
Bug: Revise the metrics docs in the website
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Apr/21 18:57
Resolved: 21/Apr/21 20:26

While inspecting the metrics code, I realized that the metrics docs (at https://cassandra.apache.org/doc/latest/operating/metrics.html) has several errors, e.g.

1.	JMX MBean names have incorrect format. They should be separated with commas, but the doc has space separated values. Cassandra users referring to this docs will not get it working. 
2.	The MBean name for Keyspace metrics is wrong. In the code, we have `keyspace=<Keyspace>`, instead of `scope=<Keyspace>`, which is listed in the docs page. 
3.	There are outdated fields. For instance, the `SyncTime` has been renamed to `RepairSyncTime` under the TableMetrics. 

To avoid frustrating and confusing the users that refer to the metrics page, the docs need to be revised.
Bug: RingTest has inconsistent assertion
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Apr/21 04:39
Resolved: 09/Aug/21 16:09

There is an assertion for the node current load like:

{noformat}
assertThat(hostRing, matchesPattern(".*\\d+\\.\\d+ KiB.*"));
{noformat}

while we are formatting that value with {{#.##}}. Therefore if we say have 46 KiB, it will be formatted as 46 KiB rather than 46.00 KiB which is expected by the test. We need to either change this assertion or change the format string to {{#0.00}}
Bug: "compression" configuration in unit tests is incorrect
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Apr/21 08:31
Resolved: 28/Apr/21 08:51

When running unit tests with "compression" configuration, we use non-default Snappy compressor.

There is a misleading fragment of {{build.xml}}:
{code}
      <property name="compressed_yaml" value="${build.test.dir}/cassandra.compressed.yaml"/>
      <concat destfile="${compressed_yaml}">
          <fileset file="${test.conf}/cassandra.yaml"/>
          <fileset file="${test.conf}/commitlog_compression.yaml"/>
      </concat>
{code}

{{cassandra.compressed.yaml}} has been replaced in CASSANDRA-14482 by two files {{commitlog_compression_LZ4.yaml}} and {{commitlog_compression_Zstd.yaml}} without changing build configuration.

All in all we could fix that but I doubt it makes any sense since {{cdc}} configuration already uses compressed commit log anyway so it feels redundant to test compression alone for each CI run.
Bug: IntelliJ configuration is broken after recent changes in build.xml
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Apr/21 07:16
Resolved: 22/Apr/21 21:41

IntelliJ configuration is broken after recent changes in build.xml

In particular, it does not resolve {{build/test/lib/jars}} as library folder

 !screenshot-1.png!
Bug: Static column added in compact tables through Cassandra-stress tool
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 18/Jun/21 11:18
Resolved: 23/Oct/21 22:43

I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
tool to create data for my cluster.


# cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
cql3 user=cassandra password=cassandra -node nodeip
I saw that two tables were created "counter1 and standard1".
The "counter1" table had no data and also was created with the following
configuration:


cassandra@cqlsh> desc table keyspace1.counter1;
cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
 key blob,
 column1 text,
 *"C0" counter static,*
 *"C1" counter static,*
 *"C2" counter static,*
 *"C3" counter static,*
 *"C4" counter static,*
 value counter,
 PRIMARY KEY (key, column1)
) *WITH COMPACT STORAGE*
 AND CLUSTERING ORDER BY (column1 ASC)
 AND bloom_filter_fp_chance = 0.01
 AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
 AND comment = ''
 AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
 AND compression = \{'enabled': 'false'}
 AND crc_check_chance = 1.0
 AND dclocal_read_repair_chance = 0.1
 AND default_time_to_live = 0
 AND gc_grace_seconds = 864000
 AND max_index_interval = 2048
 AND memtable_flush_period_in_ms = 0
 AND min_index_interval = 128
 AND read_repair_chance = 0.0
 AND speculative_retry = '99PERCENTILE';


Now if I try to create a similar schema manually with above-mentioned
schema, I get the following error. InvalidRequest: Error from server:
code=2200 [Invalid query] message="Static columns are not supported in
COMPACT STORAGE tables"

 

I further read more about this error and found that static columns cannot
be used with COMPACT STORAGE tables.
Here is the documentation for the same :

1. https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
 2. https://programmersought.com/article/81431553936/
 
I raised the same on dev as well as user Cassandra forum. I have got a reply from Benjamin Lerer that this is a bug and hence raising the JIRA.

*Query details:*
https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
Bug: Adding columns via ALTER TABLE can generate corrupt sstables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jun/21 17:51
Resolved: 21/Jun/21 14:00

This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899

Basically the column placeholders introduced in 15899 can get read-repaired in to the memtable and later flushed to disk and in some cases this can conflict with the actual column (if the actual column is a collection for example) and cause CorruptSSTableExceptions.

Fix is probably to just revert 15899, at least until if and when we find a solution that we can rely on. Will post that + test next week.
Bug: Unable to replace node with stale schema
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/May/21 23:03
Resolved: 28/May/21 23:45

 

After CASSANDRA-15158 operators are no longer permitted to replace a terminated node with a stale schema. That is, launching a node to replace NodeA in the following scenario:
{code:java}
NodeA (terminated): schema=V0
All others (alive): schema=V1{code}
yields:
{code:java}
ERROR [main] 2021-04-30 19:10:23,410 CassandraDaemon.java:822 - Exception encountered during startup
java.lang.RuntimeException: Didn't receive schemas for all known versions within the timeout
        at org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:887) ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
        at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:937) ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
        at org.apache.cassandra.service.StorageService.initServer(StorageService.java:746) ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
        at org.apache.cassandra.service.StorageService.initServer(StorageService.java:654) ~[nf-cassandra-3.0.24.1.jar:3.0.24.1]
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374) [nf-cassandra-3.0.24.1.jar:3.0.24.1]
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616) [nf-cassandra-3.0.24.1.jar:3.0.24.1]
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809) [nf-cassandra-3.0.24.1.jar:3.0.24.1]{code}
This can be reproduced like so:
 # Shut down C* on one node in a 3.0.24 cluster
 # Create a new keyspace and table from one of the other nodes
 # Terminate and replace the node on which C* was shut down.

Waiting for agreement of the nodes not being replaced seems prudent as not doing so could induce data loss, the node being replaced should be exempted from this check.

Reference CASSANDRA-16577 for more context.
Bug: Fix test testCompoundPartitionKey - org.apache.cassandra.cql3.ViewTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Apr/21 02:37
Resolved: 23/Apr/21 18:48

https://app.circleci.com/pipelines/github/dcapwell/cassandra/874/workflows/0b0a1e36-107a-43c7-815f-bf8e61d3028d/jobs/5227/tests

{code}
junit.framework.AssertionFailedError: Got more rows than expected. Expected 0 but got 1.
	at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1185)
	at org.apache.cassandra.cql3.ViewTest.testCompoundPartitionKey(ViewTest.java:817)
{code}
Bug: Flaky o.a.c.distributed.test.SchemaTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jun/21 11:38
Resolved: 22/Jun/21 14:09

The JVM dtest {{org.apache.cassandra.distributed.test.SchemaTest}} is flaky:
 [https://ci-cassandra.apache.org/job/Cassandra-4.0.0/34/testReport/junit/org.apache.cassandra.distributed.test/SchemaTest/readRepairWithCompaction_2/]
{code:java}
Error Message
FSWriteError in /home/cassandra/cassandra/tmp/dtests5018452609443646984/node2/commitlog/CommitLog-7-1624286958980.log
Stacktrace
java.lang.RuntimeException: FSWriteError in /home/cassandra/cassandra/tmp/dtests5018452609443646984/node2/commitlog/CommitLog-7-1624286958980.log
	at org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:582)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	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)
Caused by: FSWriteError in /home/cassandra/cassandra/tmp/dtests5018452609443646984/node2/commitlog/CommitLog-7-1624286958980.log
	at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:256)
	at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:273)
	at org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.handleReplayedSegment(AbstractCommitLogSegmentManager.java:349)
	at org.apache.cassandra.db.commitlog.CommitLog.recoverSegmentsOnDisk(CommitLog.java:178)
	at org.apache.cassandra.distributed.impl.Instance.lambda$startup$10(Instance.java:508)
Caused by: java.nio.file.NoSuchFileException: /home/cassandra/cassandra/tmp/dtests5018452609443646984/node2/commitlog/CommitLog-7-1624286958980.log
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
	at java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:249)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
	at java.base/java.nio.file.Files.delete(Files.java:1142)
	at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:250)
{code}
Although it doesn't fail frequently on CI it's quite easy to reproduce it locally.

I think the failure is caused by the two tests on the class not waiting for the future returned by {{IInstance#shutdown()}}.
Bug: CQL shell should prefer newer TLS version by default
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jun/21 18:28
Resolved: 20/Jul/21 19:26

This is a follow up to CASSANDRA-16695 where a patch was committed to 3.0, 3.11, 4.0 and trunk.

As part of it we saw that CQL shell python DTests are failing due to config issues for version 2.2.

As part of the current ticket we need to produce a fix to be able to run the CQL shell tests and verify and apply the patch from CASSANDRA-16695 to Cassandra 2.2
Bug: cqlsh should prefer newer TLS version by default
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/May/21 18:09
Resolved: 12/Jun/21 18:23

Some new JDK releases started to disable TLSv1.0 and TLSv1.1.

[https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]

 

However, the code in:

[https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]

is defaulting to those rather old versions,

which could lead to the following problem:
{code:java}
('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried connecting to [('10.101.34.89', 9042)]. Last error: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
 

Python2 default TLS protocol

[https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]

Python3 default TLS protocol

[https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
Bug: Unable to replace node if cluster is in mixed major version
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 11/Jun/21 08:02
Resolved: 11/Jun/21 12:11

This should be independent of cluster size, but in my example repro, I have a 6 node cluster where 5 nodes are on 3.0, one node is on 2.1, and replacing any of the 3.0 nodes (such that new node bootstraps from neighbors) fails during the bootstrap phase of the new node with the below exception.

This version of C* includes fix for CASSANDRA-16692.

{code:java}
ERROR [main] 2021-06-11 07:47:36,500 CassandraDaemon.java:822 - Exception encountered during startup
java.lang.RuntimeException: Didn't receive schemas for all known versions within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
	at org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:909) ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
	at org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:960) ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
	at org.apache.cassandra.service.StorageService.initServer(StorageService.java:751) ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
	at org.apache.cassandra.service.StorageService.initServer(StorageService.java:659) ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
	at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374) [nf-cassandra-3.0.25.1.jar:3.0.25.1]
	at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616) [nf-cassandra-3.0.25.1.jar:3.0.25.1]
	at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809) [nf-cassandra-3.0.25.1.jar:3.0.25.1]
{code}
Bug: Latest 3.x Cassandra (3.11.10) fails to start after updating corretto jdk from 8.252 to 8.292
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 28/May/21 07:43
Resolved: 27/Jul/21 01:59

Cassandra fails to start with the following exception
{code:java}
[2021-05-22 03:19:04,790] [Apache Cassandra Error] java.lang.UnsatisfiedLinkError: C:\Users\alexey.barsov\AppData\Local\Temp\jna--1630081341\jna2627169091367567840.dll: Can't find dependent libraries
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at java.lang.ClassLoader$NativeLibrary.load(Native Method)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at java.lang.Runtime.load0(Runtime.java:810)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at java.lang.System.load(System.java:1088)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at com.sun.jna.Native.<clinit>(Native.java:140)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at org.apache.cassandra.utils.WindowsTimer.<clinit>(WindowsTimer.java:35)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630)
 [2021-05-22 03:19:04,790] [Apache Cassandra Error] at com.jetbrains.cassandra.service.CassandraServiceMain.start(CassandraServiceMain.java:92)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:99)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at com.jetbrains.launcher.AppProxy$6$1.call(AppProxy.java:97)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 [2021-05-22 03:19:04,791] [Apache Cassandra Error] at java.lang.Thread.run(Thread.java:748){code}
To Reproduce
 Run Cassandra 3.11.0 on corretto jdk 8.292

Platform information
 OS: Windows 10
 Jdk Version: OpenJDK 64-Bit Server VM Corretto-8.292.10.1 (build 25.292-b10, mixed mode)

 

Note: related issue in corretto jdk 8 issue tracker: https://github.com/corretto/corretto-8/issues/308
Bug: Fix test testNullClusteringValues - org.apache.cassandra.distributed.upgrade.CompactStorage3to4UpgradeTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jun/21 20:05
Resolved: 22/Jun/21 22:29

https://app.circleci.com/pipelines/github/dcapwell/cassandra/951/workflows/d99b4bd4-935f-47fe-aaa2-85adc6b2bea0/jobs/5831

{code}
java.lang.RuntimeException: java.lang.RuntimeException: org.apache.cassandra.exceptions.InvalidRequestException: DROP COMPACT STORAGE is disabled. Enable in cassandra.yaml to use.
	at org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
	at org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$7(IsolatedExecutor.java:112)
	at org.apache.cassandra.distributed.impl.AbstractCluster.schemaChange(AbstractCluster.java:646)
	at org.apache.cassandra.distributed.impl.AbstractCluster.schemaChange(AbstractCluster.java:630)
	at org.apache.cassandra.distributed.impl.AbstractCluster.schemaChange(AbstractCluster.java:613)
	at org.apache.cassandra.distributed.upgrade.CompactStorage3to4UpgradeTest.lambda$testNullClusteringValues$1(CompactStorage3to4UpgradeTest.java:52)
	at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:187)
	at org.apache.cassandra.distributed.upgrade.CompactStorage3to4UpgradeTest.testNullClusteringValues(CompactStorage3to4UpgradeTest.java:59)
Caused by: java.lang.RuntimeException: org.apache.cassandra.exceptions.InvalidRequestException: DROP COMPACT STORAGE is disabled. Enable in cassandra.yaml to use.
	at org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:209)
	at org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$5(IsolatedExecutor.java:109)
	at org.apache.cassandra.distributed.impl.Coordinator.executeWithResult(Coordinator.java:69)
	at org.apache.cassandra.distributed.api.ICoordinator.execute(ICoordinator.java:32)
	at org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$9(AbstractCluster.java:643)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	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:83)
	at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.cassandra.exceptions.InvalidRequestException: DROP COMPACT STORAGE is disabled. Enable in cassandra.yaml to use.
	at org.apache.cassandra.cql3.statements.AlterTableStatement.announceMigration(AlterTableStatement.java:295)
	at org.apache.cassandra.cql3.statements.SchemaAlteringStatement.execute(SchemaAlteringStatement.java:123)
	at org.apache.cassandra.distributed.impl.Coordinator.executeInternal(Coordinator.java:107)
	at org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:69)
{code}