[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715853#comment-17715853
]
Stefan Miklosovic commented on CASSANDRA-18105:
-----------------------------------------------
I run the multiplexer but I am not able to run it successfully. It throws this:
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2118/workflows/1c5658d4-250e-4e5f-aedc-ad80c0127bde/jobs/24768/tests#failed-test-0
{code}
org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions
were thrown during test
at
org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:748)
at
org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:734)
at
org.apache.cassandra.distributed.test.IndexAndMVDroppingTest.shutdown(IndexAndMVDroppingTest.java:65)
Suppressed: java.lang.RuntimeException:
java.util.concurrent.ExecutionException:
org.apache.cassandra.db.compaction.CompactionInterruptedException: Compaction
interrupted: Secondary index
build@5bb59060-e29a-11ed-bded-33234da21547(distributed_test_keyspace, tb1,
8/8)bytes
at
org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:442)
at
org.apache.cassandra.index.internal.CassandraIndex.buildBlocking(CassandraIndex.java:731)
at
org.apache.cassandra.index.internal.CassandraIndex.lambda$getBuildIndexTask$5(CassandraIndex.java:701)
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)
Caused by: java.util.concurrent.ExecutionException:
org.apache.cassandra.db.compaction.CompactionInterruptedException: Compaction
interrupted: Secondary index
build@5bb59060-e29a-11ed-bded-33234da21547(distributed_test_keyspace, tb1,
8/8)bytes
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at
org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:438)
Caused by:
org.apache.cassandra.db.compaction.CompactionInterruptedException: Compaction
interrupted: Secondary index
build@5bb59060-e29a-11ed-bded-33234da21547(distributed_test_keyspace, tb1,
8/8)bytes
at
org.apache.cassandra.index.internal.CollatedViewIndexBuilder.build(CollatedViewIndexBuilder.java:69)
at
org.apache.cassandra.db.compaction.CompactionManager$14.run(CompactionManager.java:1744)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
{code}
I am not completely sure why this is happening. I tried to disable automatic
compaction but it throws it like 3 times out of 500.
3.11 PR is here https://github.com/apache/cassandra/pull/2289
In general, I have quite bad feeling about 3.11 branch. I can try this on 4.0
to see if it happens there too.
> TRUNCATED data come back after a restart or upgrade
> ---------------------------------------------------
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
> Reporter: Ke Han
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
> ----
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
> ----
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h ::FFFF:127.0.0.1 flush
> bin/nodetool -h ::FFFF:127.0.0.1 stopdaemon{code}
>
> I have put the full log to reproduce it for release 4.0.7 and 2.2.19 in the
> comments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
