ConfX created CASSANDRA-19745: --------------------------------- Summary: Schema change failed in Cassandra Dtest after node restart and upgrade but success in setup Key: CASSANDRA-19745 URL: https://issues.apache.org/jira/browse/CASSANDRA-19745 Project: Cassandra Issue Type: Bug Components: Test/dtest/java Reporter: ConfX
h2. What happened Cassandra dtest {{schemaChange}} behaves differently in {{setup}} and {{{}runAfterNodeUpgrade{}}}. h2. How to reproduce: Put the following test under {{{}cassandra/test/distributed/org/apache/cassandra/distributed/upgrade/{}}}, and build dtest jars. {code:java} package org.apache.cassandra.distributed.upgrade; public class demoUpgradeTest extends UpgradeTestBase { @Test public void firstDemoTest() throws Throwable { new TestCase() .nodes(2) .nodesToUpgrade(1) .withConfig((cfg) -> cfg.with(Feature.NETWORK, Feature.GOSSIP)) .upgradesToCurrentFrom(v3X) .setup((cluster) -> { cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck int, v1 int, PRIMARY KEY (pk, ck))")); }) .runAfterNodeUpgrade((cluster, node) -> { // let's do nothing here. }).run(); } @Test public void secondDemoTest() throws Throwable { new TestCase() .nodes(2) .nodesToUpgrade(1) .withConfig((cfg) -> cfg.with(Feature.NETWORK, Feature.GOSSIP)) .upgradesToCurrentFrom(v3X) .setup((cluster) -> { // let's do nothing here. }) .runAfterNodeUpgrade((cluster, node) -> { cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int, ck int, v1 int, PRIMARY KEY (pk, ck))")); }).run(); } } {code} Run the test with: {code:java} $ ant test-jvm-dtest-some-Duse.jdk11=true -Dtest.name=org.apache.cassandra.distributed.upgrade.demoUpgradeTest {code} firstDemoTest passes, but secondDemoTest fails with the following output: {code:java} java.lang.AssertionError: Error in test '5.0-beta2 -> [5.1]' while upgrading to '5.1'; successful upgrades [] at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:396) at org.apache.cassandra.distributed.upgrade.demoUpgradeTest.secondDemoTest(demoUpgradeTest.java:56) Caused by: java.lang.IllegalStateException: Can't commit transformations when running in gossip mode. Enable the ClusterMetadataService with `nodetool addtocms`. at org.apache.cassandra.tcm.migration.GossipProcessor.commit(GossipProcessor.java:34) at org.apache.cassandra.tcm.ClusterMetadataService$SwitchableProcessor.commit(ClusterMetadataService.java:836) at org.apache.cassandra.tcm.Processor.commit(Processor.java:45) at org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:511) at org.apache.cassandra.schema.Schema.submit(Schema.java:292) {code} As a previous issue suggested, {{schemaChange}} would fail to execute when gossip mode is disabled. However, even with gossip mode enabled, {{schemaChange}} behaves differently in {{setup}} and {{{}runAfterNodeUpgrade{}}}. Executing {{schemaChange}} in {{runAfterNodeUpgrade}} would call the {{commit}} function in [{{org.apache.cassandra.tcm.migration.GossipProcessor.java}}|https://github.com/apache/cassandra/blob/cbe07fd57e3d94a1f2512fced3f38e69ad4b3eb2/src/java/org/apache/cassandra/tcm/migration/GossipProcessor.java#L32]: {code:java} public Commit.Result commit(Entry.Id entryId, Transformation transform, Epoch lastKnown, Retry.Deadline retryPolicy) { throw new IllegalStateException("Can't commit transformations when running in gossip mode. Enable the ClusterMetadataService with `nodetool addtocms`."); } {code} which directly throws an exception. The expected behavior should be that {{schemaChange}} consistently in {{setup}} and {{{}runAfterNodeUpgrade{}}}. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org