[jira] [Commented] (CASSANDRA-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753067#comment-17753067 ] Stefan Miklosovic commented on CASSANDRA-18744: --- I am not sure from what version the bug is present but if it is true that it is in 4.0 as well we should fix it from there. I set fix versions from 4.0.x up. > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Priority: Low > Fix For: 4.0.x, 4.1.x, 5.x > > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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
[jira] [Updated] (CASSANDRA-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18744: -- Fix Version/s: 4.0.x 4.1.x 5.x > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Priority: Low > Fix For: 4.0.x, 4.1.x, 5.x > > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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
[jira] [Updated] (CASSANDRA-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18744: -- Bug Category: Parent values: Code(13163) Complexity: Normal Status: Open (was: Triage Needed) > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Priority: Low > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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
[jira] [Updated] (CASSANDRA-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
[ https://issues.apache.org/jira/browse/CASSANDRA-18744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-18744: --- Component/s: Tool/stress Discovered By: Adhoc Test Severity: Low > cassandra-stress in simplenative mode and prepared fails with exceptions > > > Key: CASSANDRA-18744 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Brad Schoening >Priority: Low > > % cassandra-stress write n=10 -mode simplenative cql3 prepared > ... > ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in > unnamed module of loader 'app') > java.lang.ClassCastException: class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error > executing: (ClassCastException): class [B cannot be cast to class > org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in > module java.base of loader 'bootstrap'; > org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed > module of loader 'app') > > at org.apache.cassandra.stress.Operation.error(Operation.java:127) > at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) > at > org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) > at > org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) > java.lang.RuntimeException: Failed to execute warmup > at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) > at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) > at org.apache.cassandra.stress.Stress.run(Stress.java:101) > at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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
[jira] [Created] (CASSANDRA-18744) cassandra-stress in simplenative mode and prepared fails with exceptions
Brad Schoening created CASSANDRA-18744: -- Summary: cassandra-stress in simplenative mode and prepared fails with exceptions Key: CASSANDRA-18744 URL: https://issues.apache.org/jira/browse/CASSANDRA-18744 Project: Cassandra Issue Type: Bug Reporter: Brad Schoening % cassandra-stress write n=10 -mode simplenative cql3 prepared ... ap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed module of loader 'app') java.lang.ClassCastException: class [B cannot be cast to class org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in module java.base of loader 'bootstrap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed module of loader 'app') java.io.IOException: Operation x10 on key(s) [4e334f364c4c4b373530]: Error executing: (ClassCastException): class [B cannot be cast to class org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in module java.base of loader 'bootstrap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed module of loader 'app') at org.apache.cassandra.stress.Operation.error(Operation.java:127) at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) at org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) at org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) at org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) at org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) java.io.IOException: Operation x10 on key(s) [373038504b3436363830]: Error executing: (ClassCastException): class [B cannot be cast to class org.apache.cassandra.transport.messages.ResultMessage$Prepared ([B is in module java.base of loader 'bootstrap'; org.apache.cassandra.transport.messages.ResultMessage$Prepared is in unnamed module of loader 'app') at org.apache.cassandra.stress.Operation.error(Operation.java:127) at org.apache.cassandra.stress.Operation.timeWithRetry(Operation.java:105) at org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:91) at org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:99) at org.apache.cassandra.stress.operations.predefined.CqlOperation.run(CqlOperation.java:242) at org.apache.cassandra.stress.StressAction$Consumer.run(StressAction.java:471) java.lang.RuntimeException: Failed to execute warmup at org.apache.cassandra.stress.StressAction.warmup(StressAction.java:128) at org.apache.cassandra.stress.StressAction.run(StressAction.java:71) at org.apache.cassandra.stress.Stress.run(Stress.java:101) at org.apache.cassandra.stress.Stress.main(Stress.java:54) -- 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
[jira] [Commented] (CASSANDRA-18717) Fix errors or remove ant javadoc task
[ https://issues.apache.org/jira/browse/CASSANDRA-18717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753032#comment-17753032 ] Ekaterina Dimitrova commented on CASSANDRA-18717: - I can take a look, but it will probably be next week. > Fix errors or remove ant javadoc task > - > > Key: CASSANDRA-18717 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18717 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Javadoc >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x, 5.1.x > > Time Spent: 20m > Remaining Estimate: 0h > > As discussed on CASSANDRA-17687, the javadoc task completes successfully, but > there are errors that deserve to be fixed if we keep the task around. > If we do not plan to use it, we should remove it and reduce the clutter. -- 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
[jira] [Updated] (CASSANDRA-18503) CircleCI java distributed tests to run in Medium containers
[ https://issues.apache.org/jira/browse/CASSANDRA-18503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18503: Test and Documentation Plan: 3.11: [https://github.com/apache/cassandra/pull/2571] CI: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2463/workflows/dcd87bad-342b-4937-bc89-7c3dfd1cea33] 4.0: [https://github.com/apache/cassandra/pull/2572] CI: $2464 [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18503-4.0] 4.1: [https://github.com/apache/cassandra/pull/2573] CI: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18503-4.1] 5.0: [https://github.com/apache/cassandra/pull/2574] CI: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18503-5.0] trunk: [https://github.com/ekaterinadimitrova2/cassandra/tree/18503-trunk] - clean cherry-pick from 5.0 and very few different commits from 5.0, so I did not start the jobs for now. Status: Patch Available (was: In Progress) > CircleCI java distributed tests to run in Medium containers > --- > > Key: CASSANDRA-18503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18503 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x, 5.1.x > > > With the paid configuration we have in-tree it is enough to run the java > distributed upgrade tests in Medium containers, instead of Large containers -- 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
[jira] [Commented] (CASSANDRA-18503) CircleCI java distributed tests to run in Medium containers
[ https://issues.apache.org/jira/browse/CASSANDRA-18503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753030#comment-17753030 ] Ekaterina Dimitrova commented on CASSANDRA-18503: - The below patch makes all in-JVM tests (regular and upgrade ones) run in Medium containers. (3.0 tests are already running in Medium containers) The names of the executors are not ideal, but we should open a new ticket just for naming. While working on the ticket, I noticed we still need J11 on J8 in-JVM tests job for 4.0. I will open a follow-up ticket. I noticed the jobs ran longer on cassandra-4.0 compared to other branches, but the parallelism, container size, and the number of tests seem ok to me, so I suspect it was some CircleCI delay. 3.11: [https://github.com/apache/cassandra/pull/2571] CI: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2463/workflows/dcd87bad-342b-4937-bc89-7c3dfd1cea33] 4.0: [https://github.com/apache/cassandra/pull/2572] CI: $2464 [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18503-4.0] 4.1: [https://github.com/apache/cassandra/pull/2573] CI: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18503-4.1] 5.0: [https://github.com/apache/cassandra/pull/2574] CI: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18503-5.0] trunk: [https://github.com/ekaterinadimitrova2/cassandra/tree/18503-trunk] - clean cherry-pick from 5.0 and very few different commits from 5.0, so I did not start the jobs for now. [~adelapena] , do you mind reviewing? > CircleCI java distributed tests to run in Medium containers > --- > > Key: CASSANDRA-18503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18503 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x, 5.1.x > > > With the paid configuration we have in-tree it is enough to run the java > distributed upgrade tests in Medium containers, instead of Large containers -- 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
[jira] [Created] (CASSANDRA-18743) Remove dependency on archived project metrics-reporter-config
Abe Ratnofsky created CASSANDRA-18743: - Summary: Remove dependency on archived project metrics-reporter-config Key: CASSANDRA-18743 URL: https://issues.apache.org/jira/browse/CASSANDRA-18743 Project: Cassandra Issue Type: Improvement Components: Local/Config Reporter: Abe Ratnofsky metrics-reporter-config has been archived for over 3 years, and has received no updates in nearly 6 years: https://github.com/addthis/metrics-reporter-config metrics-reporter-config processes YAML unsafely: https://github.com/addthis/metrics-reporter-config/blob/master/reporter-config-base/src/main/java/com/addthis/metrics/reporter/config/AbstractReporterConfig.java#L39C34-L39C45 This is related to CASSANDRA-18614, which is focused on migrating to safe YAML processing for the main configuration files. -- 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
[jira] [Updated] (CASSANDRA-18503) CircleCI java distributed tests to run in Medium containers
[ https://issues.apache.org/jira/browse/CASSANDRA-18503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18503: Fix Version/s: 5.1.x > CircleCI java distributed tests to run in Medium containers > --- > > Key: CASSANDRA-18503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18503 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.x, 5.1.x > > > With the paid configuration we have in-tree it is enough to run the java > distributed upgrade tests in Medium containers, instead of Large containers -- 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
[jira] [Updated] (CASSANDRA-18329) Upgrade jamm; fix eclipse problems
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18329: Summary: Upgrade jamm; fix eclipse problems (was: Upgrade jamm; fix eclipse problems and fix MemtableSizeTestBase (testSize not running in CI)) > Upgrade jamm; fix eclipse problems > -- > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 5.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- 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
[jira] [Commented] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752920#comment-17752920 ] Ekaterina Dimitrova commented on CASSANDRA-18688: - On second thought we left in 5.0 people not to be able to run Cassandra on versions between 11 and 17 at all. I am not sure it makes sense to allow it now for 5.1... It will probably be better and easier to get a flag only for post-J17 versions and keep not allowing the LTS versions between 11 and 17 at all. I am curious what a second reviewer would say. Not sure whether it is worth it an ML thread > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.1.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Commented] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752919#comment-17752919 ] Ekaterina Dimitrova commented on CASSANDRA-18688: - Overall LGTM, I left just two small comments on the PR for your consideration: * suggestion to change a bit the error message * I think we should use the JVM11 options files for versions between J11 and J17 and the J17 files for anything 17 and beyond 17. * We need similar changes to be applied to tools/bin/cassandra.in.sh (similar to bin/cassandra.in.sh) Sanity check CI run stared here, to ensure I did not miss anything: [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18688] > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.1.x > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Updated] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18688: Fix Version/s: 5.1.x > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Fix For: 5.1.x > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Updated] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18688: Summary: Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out of that (was: Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that) > Limit Java runtime in 5.0 to JDK 11 and 17 in scripts; add a flag to opt out > of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Commented] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752916#comment-17752916 ] Ekaterina Dimitrova commented on CASSANDRA-18688: - Thank you [~skokoori] I'll take a look. We also need a second committer to review the patch, so I moved the ticket to NEEDS COMMITTER. > Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Updated] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18688: Reviewers: Ekaterina Dimitrova > Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Updated] (CASSANDRA-18688) Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that
[ https://issues.apache.org/jira/browse/CASSANDRA-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18688: Status: Needs Committer (was: Patch Available) > Limit Java runtime in 5.0 to JDK17 in scripts; add a flag to opt out of that > > > Key: CASSANDRA-18688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18688 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: shylaja kokoori >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we limit our users from building with non-default Java versions in > build.xml. > They can easily hack build.xml for test purposes with different versions. > Cassandra–5.0 will be run on JDK11 and JDK17, but on startup, we do not limit > people to those two, but only to everything >= 11. We should also put an > upper limit of 17 in our Cassandra startup scripts. We can also add a flag to > opt-out if someone wants to test with newer versions. -- 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
[jira] [Commented] (CASSANDRA-18738) Update the How to Commit page after CASSANDRA-18618
[ https://issues.apache.org/jira/browse/CASSANDRA-18738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752912#comment-17752912 ] Ekaterina Dimitrova commented on CASSANDRA-18738: - Applied tehe fixes. Wanna take another look, [~mck] ? Also, just to confirm the website process as I haven't committed there anything for a while. We commit to trunk. This triggers Jenkins, on completion - we can see the staged website andd if there is nothing wrong - merge asf-staging to asf-site. Is this still the correct process? > Update the How to Commit page after CASSANDRA-18618 > --- > > Key: CASSANDRA-18738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18738 > Project: Cassandra > Issue Type: Task > Components: Legacy/Documentation and Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > In CASSANDRA-18618, checks like rat and checkstyle were moved to a separate > ant task - "check". > We need to update our How to commit page that on branches Cassandra-5.0 + we > need to run now ant realclean && ant jar build-test check pre-commit. While > on that, we already have the cassandra-5.0 branch, so that we can add that > too. -- 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
[jira] [Updated] (CASSANDRA-18742) Remove crcCheckChance and deprecated options in CompressionParams
[ https://issues.apache.org/jira/browse/CASSANDRA-18742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18742: -- Status: In Progress (was: Patch Available) > Remove crcCheckChance and deprecated options in CompressionParams > - > > Key: CASSANDRA-18742 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18742 > Project: Cassandra > Issue Type: Task > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > These should go away (1). They were deprecated like 8 years ago in > CASSANDRA-9712 and CASSANDRA-9839. > We should also remove this (2). That is a little bit more tricky but nothing > special I would say ... > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L86-L88 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L96-L97 -- 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
[jira] [Comment Edited] (CASSANDRA-18706) Test failure: org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from org.apache.cassandra.cql3.ViewTest-compression.jdk11)
[
https://issues.apache.org/jira/browse/CASSANDRA-18706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752907#comment-17752907
]
Brandon Williams edited comment on CASSANDRA-18706 at 8/10/23 7:16 PM:
---
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and makes no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/https://github.com/driftx/cassandra/commit/4c927e45c8cb29abb315dfa6c9e6e9f1d8ec6839].
was (Author: brandon.williams):
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and makes no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/019fe3fd7a05061d0365b36df446644b87e5ad68].
> Test failure:
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from
> org.apache.cassandra.cql3.ViewTest-compression.jdk11)
> ---
>
> Key: CASSANDRA-18706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18706
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.cql3/ViewTest/testIgnoreUpdate_compression_jdk11/]
> h3.
> {code:java}
> Error Message
> expected:<1> but was:<2>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<2> at
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate(ViewTest.java:328) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
>
>
--
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
[jira] [Comment Edited] (CASSANDRA-18706) Test failure: org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from org.apache.cassandra.cql3.ViewTest-compression.jdk11)
[
https://issues.apache.org/jira/browse/CASSANDRA-18706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752907#comment-17752907
]
Brandon Williams edited comment on CASSANDRA-18706 at 8/10/23 7:16 PM:
---
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and makes no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/4c927e45c8cb29abb315dfa6c9e6e9f1d8ec6839].
was (Author: brandon.williams):
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and makes no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/https://github.com/driftx/cassandra/commit/4c927e45c8cb29abb315dfa6c9e6e9f1d8ec6839].
> Test failure:
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from
> org.apache.cassandra.cql3.ViewTest-compression.jdk11)
> ---
>
> Key: CASSANDRA-18706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18706
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.cql3/ViewTest/testIgnoreUpdate_compression_jdk11/]
> h3.
> {code:java}
> Error Message
> expected:<1> but was:<2>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<2> at
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate(ViewTest.java:328) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
>
>
--
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
[jira] [Updated] (CASSANDRA-18706) Test failure: org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from org.apache.cassandra.cql3.ViewTest-compression.jdk11)
[
https://issues.apache.org/jira/browse/CASSANDRA-18706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18706:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Test failure:
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from
> org.apache.cassandra.cql3.ViewTest-compression.jdk11)
> ---
>
> Key: CASSANDRA-18706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18706
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.cql3/ViewTest/testIgnoreUpdate_compression_jdk11/]
> h3.
> {code:java}
> Error Message
> expected:<1> but was:<2>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<2> at
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate(ViewTest.java:328) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
>
>
--
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
[jira] [Comment Edited] (CASSANDRA-18706) Test failure: org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from org.apache.cassandra.cql3.ViewTest-compression.jdk11)
[
https://issues.apache.org/jira/browse/CASSANDRA-18706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752907#comment-17752907
]
Brandon Williams edited comment on CASSANDRA-18706 at 8/10/23 7:10 PM:
---
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and makes no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/019fe3fd7a05061d0365b36df446644b87e5ad68].
was (Author: brandon.williams):
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and make no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/019fe3fd7a05061d0365b36df446644b87e5ad68].
> Test failure:
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from
> org.apache.cassandra.cql3.ViewTest-compression.jdk11)
> ---
>
> Key: CASSANDRA-18706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18706
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.cql3/ViewTest/testIgnoreUpdate_compression_jdk11/]
> h3.
> {code:java}
> Error Message
> expected:<1> but was:<2>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<2> at
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate(ViewTest.java:328) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
>
>
--
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
[jira] [Commented] (CASSANDRA-18706) Test failure: org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from org.apache.cassandra.cql3.ViewTest-compression.jdk11)
[
https://issues.apache.org/jira/browse/CASSANDRA-18706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752907#comment-17752907
]
Brandon Williams commented on CASSANDRA-18706:
--
I want to note that it doesn't really make sense for this test to assert there
is only one sstable, as it's not really concerned with that and make no
guarantees for it. That said, I still wanted to know what was happening so I
added some debugging
[here|https://github.com/driftx/cassandra/commits/CASSANDRA-18706-trunk] and
ran circle to failure
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/1175/workflows/a9634ac0-120c-40d3-b800-0745b2ca8827/jobs/42078/tests].
Here we find the culprit:
{noformat}
[junit-timeout] INFO [OptionalTasks:1] 2023-08-10 17:35:42,520
ColumnFamilyStore.java:1017 - Enqueuing flush of cql_test_keyspace.mv_51,
Reason: COMMITLOG_DIRTY, Usage: 412B (0%) on-heap, 44B (0%) off-heap
{noformat}
The simplest way to fix this is allow two sstables, which I added on top of the
improved error message
[here|https://github.com/driftx/cassandra/commit/019fe3fd7a05061d0365b36df446644b87e5ad68].
> Test failure:
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate-compression.jdk11 (from
> org.apache.cassandra.cql3.ViewTest-compression.jdk11)
> ---
>
> Key: CASSANDRA-18706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18706
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here -
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1650/testReport/junit/org.apache.cassandra.cql3/ViewTest/testIgnoreUpdate_compression_jdk11/]
> h3.
> {code:java}
> Error Message
> expected:<1> but was:<2>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1> but was:<2> at
> org.apache.cassandra.cql3.ViewTest.testIgnoreUpdate(ViewTest.java:328) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> {code}
>
>
--
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
[jira] [Updated] (CASSANDRA-18742) Remove crcCheckChance and deprecated options in CompressionParams
[ https://issues.apache.org/jira/browse/CASSANDRA-18742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18742: -- Test and Documentation Plan: CI Status: Patch Available (was: In Progress) > Remove crcCheckChance and deprecated options in CompressionParams > - > > Key: CASSANDRA-18742 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18742 > Project: Cassandra > Issue Type: Task > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > These should go away (1). They were deprecated like 8 years ago in > CASSANDRA-9712 and CASSANDRA-9839. > We should also remove this (2). That is a little bit more tricky but nothing > special I would say ... > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L86-L88 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L96-L97 -- 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
[jira] [Updated] (CASSANDRA-18683) Expose per partition on-disk usage through new DataFrame that utilizes the Index.db SSTable file components.
[ https://issues.apache.org/jira/browse/CASSANDRA-18683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-18683: -- Test and Documentation Plan: ci Status: Patch Available (was: Open) > Expose per partition on-disk usage through new DataFrame that utilizes the > Index.db SSTable file components. > > > Key: CASSANDRA-18683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18683 > Project: Cassandra > Issue Type: New Feature > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > This addition to Cassandra Analytics provides a new > PartitionSizeTableProvider that generates a DataFrame returning the > compressed and uncompressed partition sizes for all partitions in a table by > utilizing the Index.db SSTable file component. -- 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
[jira] [Updated] (CASSANDRA-18683) Expose per partition on-disk usage through new DataFrame that utilizes the Index.db SSTable file components.
[ https://issues.apache.org/jira/browse/CASSANDRA-18683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-18683: -- Status: Review In Progress (was: Patch Available) > Expose per partition on-disk usage through new DataFrame that utilizes the > Index.db SSTable file components. > > > Key: CASSANDRA-18683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18683 > Project: Cassandra > Issue Type: New Feature > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > This addition to Cassandra Analytics provides a new > PartitionSizeTableProvider that generates a DataFrame returning the > compressed and uncompressed partition sizes for all partitions in a table by > utilizing the Index.db SSTable file component. -- 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
[cassandra-website] branch asf-staging updated (d1ebb498b -> 070140327)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard d1ebb498b generate docs for f02aa10d new 070140327 generate docs for f02aa10d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d1ebb498b) \ N -- N -- N refs/heads/asf-staging (070140327) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4852435 -> 4852435 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18683) Expose per partition on-disk usage through new DataFrame that utilizes the Index.db SSTable file components.
[ https://issues.apache.org/jira/browse/CASSANDRA-18683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Berragan updated CASSANDRA-18683: --- Change Category: Operability Complexity: Normal Reviewers: Yifan Cai Status: Open (was: Triage Needed) > Expose per partition on-disk usage through new DataFrame that utilizes the > Index.db SSTable file components. > > > Key: CASSANDRA-18683 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18683 > Project: Cassandra > Issue Type: New Feature > Components: Analytics Library >Reporter: James Berragan >Assignee: James Berragan >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > This addition to Cassandra Analytics provides a new > PartitionSizeTableProvider that generates a DataFrame returning the > compressed and uncompressed partition sizes for all partitions in a table by > utilizing the Index.db SSTable file component. -- 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
[jira] [Commented] (CASSANDRA-18673) Reduce size of per-SSTable index components
[
https://issues.apache.org/jira/browse/CASSANDRA-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752874#comment-17752874
]
Caleb Rackliffe commented on CASSANDRA-18673:
-
+1
I'm guessing the 5.0 and trunk patches will be identical, since we just created
{{cassandra-5.0}}...
> Reduce size of per-SSTable index components
> ---
>
> Key: CASSANDRA-18673
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18673
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Urgent
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> The current per-SSTable index components are large because the primary keys
> that are stored in them include the token as part of the byte comparable. The
> byte comparable puts the token first meaning that we get very little prefix
> compression from either the trie or the sorted terms store.
> We can fix this by removing the token from the primary key serialization.
> This would allow us to get the prefix compression from the trie and the
> sorted terms store.
--
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
[jira] [Updated] (CASSANDRA-18742) Remove crcCheckChance and deprecated options in CompressionParams
[ https://issues.apache.org/jira/browse/CASSANDRA-18742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18742: -- Fix Version/s: 5.x > Remove crcCheckChance and deprecated options in CompressionParams > - > > Key: CASSANDRA-18742 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18742 > Project: Cassandra > Issue Type: Task > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > These should go away (1). They were deprecated like 8 years ago in > CASSANDRA-9712 and CASSANDRA-9839. > We should also remove this (2). That is a little bit more tricky but nothing > special I would say ... > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L86-L88 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L96-L97 -- 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
[jira] [Updated] (CASSANDRA-18742) Remove crcCheckChance and deprecated options in CompressionParams
[ https://issues.apache.org/jira/browse/CASSANDRA-18742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18742: -- Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > Remove crcCheckChance and deprecated options in CompressionParams > - > > Key: CASSANDRA-18742 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18742 > Project: Cassandra > Issue Type: Task > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > > These should go away (1). They were deprecated like 8 years ago in > CASSANDRA-9712 and CASSANDRA-9839. > We should also remove this (2). That is a little bit more tricky but nothing > special I would say ... > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L86-L88 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L96-L97 -- 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
[jira] [Updated] (CASSANDRA-18742) Remove crcCheckChance and deprecated options in CompressionParams
[ https://issues.apache.org/jira/browse/CASSANDRA-18742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18742: -- Description: These should go away (1). They were deprecated like 8 years ago in CASSANDRA-9712 and CASSANDRA-9839. We should also remove this (2). That is a little bit more tricky but nothing special I would say ... (1) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L86-L88 (2) https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L96-L97 > Remove crcCheckChance and deprecated options in CompressionParams > - > > Key: CASSANDRA-18742 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18742 > Project: Cassandra > Issue Type: Task > Components: Feature/Compression >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > These should go away (1). They were deprecated like 8 years ago in > CASSANDRA-9712 and CASSANDRA-9839. > We should also remove this (2). That is a little bit more tricky but nothing > special I would say ... > (1) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L86-L88 > (2) > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/CompressionParams.java#L96-L97 -- 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
[jira] [Created] (CASSANDRA-18742) Remove crcCheckChance and deprecated options in CompressionParams
Stefan Miklosovic created CASSANDRA-18742: - Summary: Remove crcCheckChance and deprecated options in CompressionParams Key: CASSANDRA-18742 URL: https://issues.apache.org/jira/browse/CASSANDRA-18742 Project: Cassandra Issue Type: Task Components: Feature/Compression Reporter: Stefan Miklosovic Assignee: Stefan Miklosovic -- 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
[jira] [Updated] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18741: Reviewers: Brandon Williams, Ekaterina Dimitrova, Caleb Rackliffe Brandon Williams, Ekaterina Dimitrova, Caleb Rackliffe (was: Brandon Williams, Caleb Rackliffe, Ekaterina Dimitrova) Status: Review In Progress (was: Patch Available) > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Updated] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18741: Status: Ready to Commit (was: Review In Progress) > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Updated] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18741: Reviewers: Brandon Williams, Ekaterina Dimitrova (was: Brandon Williams, Caleb Rackliffe, Ekaterina Dimitrova) > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Updated] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18741: Test and Documentation Plan: n/a Status: Patch Available (was: In Progress) Patch: https://github.com/apache/cassandra/pull/2569 CI (unit tests only): https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-18741-5.0 > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752854#comment-17752854 ] Ekaterina Dimitrova commented on CASSANDRA-18741: - bq. If we're just flipping a boolean in a config I think you're good to commit. +1 > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752852#comment-17752852 ] Brandon Williams commented on CASSANDRA-18741: -- If we're just flipping a boolean in a config I think you're good to commit. > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752850#comment-17752850 ] Caleb Rackliffe commented on CASSANDRA-18741: - That sounds fine to me...will push up a patch shortly... > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Assigned] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe reassigned CASSANDRA-18741: --- Assignee: Caleb Rackliffe > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Comment Edited] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752832#comment-17752832
]
Maxim Muzafarov edited comment on CASSANDRA-18737 at 8/10/23 3:05 PM:
--
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the {{ColumnFamilyStore#truncateBlocking}} is called to
release the resources, but in this particular test it is not. The second one is
the exception mentioned in the issue description - the above error appears in
the log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
btw:
{{\{KEYSPACE1, CF_SNAPSHOTS}}} is missed in the cleanup as well.
was (Author: mmuzaf):
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the {{ColumnFamilyStore#truncateBlocking}} is called to
release the resources, but in this particular test it is not. The second one is
the exception mentioned in the issue description - the above error appears in
the log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
btw:
{{SchemaLoader.standardCFMD(KEYSPACE1, CF_SNAPSHOTS)}} is missed in the cleanup
as well.
> Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest
> (testLoadingIncompleteSSTable-.jdk17)
> -
>
> Key: CASSANDRA-18737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18737
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.RuntimeException: Failed to list files in
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
> at
> org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:213)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5/nc-17-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
> at
> java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
> Caused by: java.lang.NullPointerException
> at
> com.google.common.base.P
[jira] [Comment Edited] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752832#comment-17752832
]
Maxim Muzafarov edited comment on CASSANDRA-18737 at 8/10/23 2:58 PM:
--
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the {{ColumnFamilyStore#truncateBlocking}} is called to
release the resources, but in this particular test it is not. The second one is
the exception mentioned in the issue description - the above error appears in
the log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
btw:
{{SchemaLoader.standardCFMD(KEYSPACE1, CF_SNAPSHOTS)}} is missed in the cleanup
as well.
was (Author: mmuzaf):
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the {{ColumnFamilyStore#truncateBlocking}} is called to
release the resources, but in this particular test it is not. The second one is
the exception mentioned in the issue description - the above error appears in
the log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
> Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest
> (testLoadingIncompleteSSTable-.jdk17)
> -
>
> Key: CASSANDRA-18737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18737
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.RuntimeException: Failed to list files in
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
> at
> org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:213)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5/nc-17-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
> at
> java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
> Caused by: java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:903)
> at
> org.apa
[jira] [Comment Edited] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752832#comment-17752832
]
Maxim Muzafarov edited comment on CASSANDRA-18737 at 8/10/23 2:57 PM:
--
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the {{ColumnFamilyStore#truncateBlocking}} is called to
release the resources, but in this particular test it is not. The second one is
the exception mentioned in the issue description - the above error appears in
the log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
was (Author: mmuzaf):
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the ColumnFamilyStore#truncateBlocking is called to release
the resources, but in this particular test it is not. The second one is the
exception mentioned in the issue description - the above error appears in the
log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
> Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest
> (testLoadingIncompleteSSTable-.jdk17)
> -
>
> Key: CASSANDRA-18737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18737
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.RuntimeException: Failed to list files in
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
> at
> org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:213)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5/nc-17-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
> at
> java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
> Caused by: java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:903)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.buildSummaryAndBloomFilter(BigSST
[jira] [Comment Edited] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752824#comment-17752824
]
Maxim Muzafarov edited comment on CASSANDRA-18737 at 8/10/23 2:56 PM:
--
{code}
[junit-timeout] ERROR [Reference-Reaper] 2023-08-10 14:33:45,219 Ref.java:240 -
LEAK DETECTED: a reference (class
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1954732867:/tmp/10654893319199153835/SSTableLoaderTest/Standard2-e6b6fab0378a11eebf94c5a5ea4e0fa0/nc-14-big)
to class
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1954732867:/tmp/10654893319199153835/SSTableLoaderTest/Standard2-e6b6fab0378a11eebf94c5a5ea4e0fa0/nc-14-big
was not released before the reference was garbage collected
[junit-timeout] ERROR [Reference-Reaper] 2023-08-10 14:33:45,220 Ref.java:280 -
Allocate trace class
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1954732867:/tmp/10654893319199153835/SSTableLoaderTest/Standard2-e6b6fab0378a11eebf94c5a5ea4e0fa0/nc-14-big:
[junit-timeout] Thread[main,5,main]
[junit-timeout] at
java.base/java.lang.Thread.getStackTrace(Thread.java:1610)
[junit-timeout] at
org.apache.cassandra.utils.concurrent.Ref$Debug.(Ref.java:270)
[junit-timeout] at
org.apache.cassandra.utils.concurrent.Ref$State.(Ref.java:191)
[junit-timeout] at
org.apache.cassandra.utils.concurrent.Ref.(Ref.java:113)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.SSTableReader.(SSTableReader.java:467)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.SSTableReaderWithFilter.(SSTableReaderWithFilter.java:43)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.big.BigTableReader.(BigTableReader.java:100)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.big.BigTableReader$Builder.buildInternal(BigTableReader.java:742)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.big.BigTableReader$Builder.buildInternal(BigTableReader.java:693)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.SSTableReader$Builder.build(SSTableReader.java:1890)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:97)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
[junit-timeout] at
org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
[junit-timeout] at
org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
[junit-timeout] at
org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
[junit-timeout] at
java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
[junit-timeout] at
java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
[junit-timeout] at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
[junit-timeout] at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
[junit-timeout] at
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
[junit-timeout] at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
[junit-timeout] at
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
[junit-timeout] at
org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
[junit-timeout] at
org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
[junit-timeout] at
org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
[junit-timeout] at
org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
[junit-timeout] at
org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
[junit-timeout] at
org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:225)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] at
java.base/java.lang.reflect.Method.invoke(Method.java:568)
[junit-timeout] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
[junit-timeout] at
org.junit.internal.runners.model.Reflect
[jira] [Commented] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752832#comment-17752832
]
Maxim Muzafarov commented on CASSANDRA-18737:
-
There are a couple of unrelated exceptions in the logs. The first is when the
resources are not released properly after the test, so they throw an exception
- in other tests the ColumnFamilyStore#truncateBlocking is called to release
the resources, but in this particular test it is not. The second one is the
exception mentioned in the issue description - the above error appears in the
log at the same time as the {{NullPointerException}} is thrown.
Here:
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/290/workflows/09943d9e-5026-4fbb-8c79-d3208dab87a2/jobs/20389/parallel-runs/5
> Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest
> (testLoadingIncompleteSSTable-.jdk17)
> -
>
> Key: CASSANDRA-18737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18737
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.RuntimeException: Failed to list files in
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
> at
> org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:213)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5/nc-17-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
> at
> java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
> Caused by: java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:903)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.buildSummaryAndBloomFilter(BigSSTableReaderLoadingBuilder.java:193)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:116)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:58)
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:92)
> {noformat}
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1174/workflows/263f1e22-e4d0-48b8-b3e2-496edb30a068/jobs/41924/tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752827#comment-17752827 ] Ekaterina Dimitrova edited comment on CASSANDRA-18741 at 8/10/23 2:44 PM: -- It seems HeapUtilsTest sets it explicitly to true for testing and then sets it back to false. I agree we can probably set it to false iin the unit tests cassandra.yaml and revert only during debugging but let's see what [~jmckenzie] and [~maedhroz] miight have to say here. was (Author: e.dimitrova): It seems HeapUtilsTest sets it to true for testing and then sets it back to false. I agree we can probably set it to false iin the unit tests cassandra.yaml and revert only during debugging but let's see what [~jmckenzie] and [~maedhroz] miight have to say here. > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Comment Edited] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752827#comment-17752827 ] Ekaterina Dimitrova edited comment on CASSANDRA-18741 at 8/10/23 2:44 PM: -- It seems HeapUtilsTest sets it to true for testing and then sets it back to false. I agree we can probably set it to false iin the unit tests cassandra.yaml and revert only during debugging but let's see what [~jmckenzie] and [~maedhroz] miight have to say here. was (Author: e.dimitrova): It seems HeapUtilsTest sets it to true for testing and then sets it back to false. I agree we can probably set it to false and revert only during debugging but let's see what [~jmckenzie] and [~maedhroz] miight have to say here. > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752827#comment-17752827 ] Ekaterina Dimitrova commented on CASSANDRA-18741: - It seems HeapUtilsTest sets it to true for testing and then sets it back to false. I agree we can probably set it to false and revert only during debugging but let's see what [~jmckenzie] and [~maedhroz] miight have to say here. > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18705) Create release branch cassandra-5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-18705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752826#comment-17752826
]
Michael Semb Wever commented on CASSANDRA-18705:
Good catch [~brandon.williams] – there's a number of
{{upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_5_0_x_To_indev_trunk}}
failures against both the 5.0 and trunk patches. Will investigate…
> Create release branch cassandra-5.0
> ---
>
> Key: CASSANDRA-18705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18705
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code:java}
> git switch -c cassandra-5.0 trunk
> git push --set-upstream origin cassandra-5.0
> {code}
> 2. Bump trunk's version
> {code:java}
> git switch trunk
> # increment version to 5.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
> circleci and in-tree scripts)
> -
> [https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96]
> - [https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374]
> - [https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85]
> 3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1` to
> jira versions
> (no existing tickets will be changed - assignees need to change appropriate
> bugs from 5.x to what is appropriate…)
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> [https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51]
> 6. Add dtest version and upgrade paths
> -
> [https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py]
> -
> [https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41]
> 7. Update how_to_commit documentation
> [https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc]
> 8. Update website CI to trigger off cassandra-5.0 builds
> -
> [https://github.com/apache/cassandra-builds/commit/1fc9b5ee71dc37e1145f276ead5c680c6b3fe3db]
--
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
[jira] [Commented] (CASSANDRA-18737) Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest (testLoadingIncompleteSSTable-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752824#comment-17752824
]
Maxim Muzafarov commented on CASSANDRA-18737:
-
{code}
[junit-timeout] ERROR [Reference-Reaper] 2023-08-10 14:33:45,219 Ref.java:240 -
LEAK DETECTED: a reference (class
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1954732867:/tmp/10654893319199153835/SSTableLoaderTest/Standard2-e6b6fab0378a11eebf94c5a5ea4e0fa0/nc-14-big)
to class
org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1954732867:/tmp/10654893319199153835/SSTableLoaderTest/Standard2-e6b6fab0378a11eebf94c5a5ea4e0fa0/nc-14-big
was not released before the reference was garbage collected
{code}
> Test failure: org.apache.cassandra.io.sstable.SSTableLoaderTest
> (testLoadingIncompleteSSTable-.jdk17)
> -
>
> Key: CASSANDRA-18737
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18737
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.RuntimeException: Failed to list files in
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:77)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.getFiles(LifecycleTransaction.java:626)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.openSSTables(SSTableLoader.java:103)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:202)
> at
> org.apache.cassandra.io.sstable.SSTableLoaderTest.testLoadingIncompleteSSTable(SSTableLoaderTest.java:213)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException:
> Corrupted:
> /tmp/1409486429862512729/SSTableLoaderTest/Standard2-57877ac036d311eea01f83fcb8f6fee5/nc-17-big
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:111)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:397)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.openForBatch(SSTableReader.java:373)
> at
> org.apache.cassandra.io.sstable.SSTableLoader.lambda$openSSTables$0(SSTableLoader.java:152)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.lambda$innerList$2(LogAwareFileLister.java:99)
> at
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:178)
> at
> java.base/java.util.TreeMap$EntrySpliterator.forEachRemaining(TreeMap.java:3287)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.innerList(LogAwareFileLister.java:101)
> at
> org.apache.cassandra.db.lifecycle.LogAwareFileLister.list(LogAwareFileLister.java:73)
> Caused by: java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:903)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.buildSummaryAndBloomFilter(BigSSTableReaderLoadingBuilder.java:193)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:116)
> at
> org.apache.cassandra.io.sstable.format.big.BigSSTableReaderLoadingBuilder.openComponents(BigSSTableReaderLoadingBuilder.java:58)
> at
> org.apache.cassandra.io.sstable.format.SSTableReaderLoadingBuilder.build(SSTableReaderLoadingBuilder.java:92)
> {noformat}
> Seen here:
> https://app.circleci.com/pipelines/github/driftx/cassandra/1174/workflows/263f1e22-e4d0-48b8-b3e2-496edb30a068/jobs/41924/tests
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752823#comment-17752823 ] Brandon Williams commented on CASSANDRA-18741: -- I can see how setting it to true made sense for tests since if they do crash we probably want the dump, but I think in practice this instead just generates a lot of cruft we don't need or want. I propose setting it to false in test/conf/cassandra.yaml. > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Updated] (CASSANDRA-18738) Update the How to Commit page after CASSANDRA-18618
[ https://issues.apache.org/jira/browse/CASSANDRA-18738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18738: Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) > Update the How to Commit page after CASSANDRA-18618 > --- > > Key: CASSANDRA-18738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18738 > Project: Cassandra > Issue Type: Task > Components: Legacy/Documentation and Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > In CASSANDRA-18618, checks like rat and checkstyle were moved to a separate > ant task - "check". > We need to update our How to commit page that on branches Cassandra-5.0 + we > need to run now ant realclean && ant jar build-test check pre-commit. While > on that, we already have the cassandra-5.0 branch, so that we can add that > too. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752815#comment-17752815 ] Ekaterina Dimitrova commented on CASSANDRA-18741: - The maybeCreateHeapDump was added only in 5.0 as part of CASSANDRA-17795 - Add ability to generate a one-time heap dump output to a file on Unhandled Exceptions. While running RandomSchemaTest, a breakpoint points to the JVMStabilityInspector and the Commit Log Service. By default dump_heap_on_uncaught_exception is false. Though in the logs of RandomSchemaTest it is indeed dump_heap_on_uncaught_exception=true and I can see that CASSANDRA-17795 set the flag to true for unit tests. > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752816#comment-17752816 ] Ekaterina Dimitrova commented on CASSANDRA-18741: - It seems our comments crashed :D > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752812#comment-17752812 ] Brandon Williams commented on CASSANDRA-18741: -- This bisected to CASSANDRA-17795, which makes sense. /cc [~jmckenzie] [~maedhroz] > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[cassandra-website] branch asf-staging updated (21fb44509 -> d1ebb498b)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 21fb44509 generate docs for f02aa10d new d1ebb498b generate docs for f02aa10d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (21fb44509) \ N -- N -- N refs/heads/asf-staging (d1ebb498b) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4852435 -> 4852435 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18740:
--
Fix Version/s: 5.0
5.1
(was: 5.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/63196006637af745376b778eb9a689c7a928358e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0, 5.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5
[cassandra] branch cassandra-5.0 updated (726e2aab01 -> 6319600663)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 726e2aab01 Merge branch 'cassandra-4.1' into cassandra-5.0 add 6319600663 Fix compilation warnings in RandomSchemaTest No new revisions were added by this update. Summary of changes: .../org/apache/cassandra/cql3/RandomSchemaTest.java| 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 7022d1a5e6cf2d97b1e817ef1824eff7ede09c4d Merge: 798edb3edd 6319600663 Author: Stefan Miklosovic AuthorDate: Thu Aug 10 14:45:41 2023 +0200 Merge branch 'cassandra-5.0' into trunk .../org/apache/cassandra/cql3/RandomSchemaTest.java| 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (798edb3edd -> 7022d1a5e6)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 798edb3edd Merge branch 'cassandra-5.0' into trunk add 6319600663 Fix compilation warnings in RandomSchemaTest new 7022d1a5e6 Merge branch 'cassandra-5.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../org/apache/cassandra/cql3/RandomSchemaTest.java| 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752791#comment-17752791
]
Stefan Miklosovic edited comment on CASSANDRA-18740 at 8/10/23 1:37 PM:
j17
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2877/workflows/ab3db145-8458-4110-8c37-0de0b3871807
j11 just units
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2877/workflows/ed042a5c-b1c9-4d32-ace5-4c47bae35d62/jobs/95266
was (Author: smiklosovic):
j17
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2877/workflows/ab3db145-8458-4110-8c37-0de0b3871807
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to
[jira] [Commented] (CASSANDRA-18705) Create release branch cassandra-5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-18705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752804#comment-17752804
]
Michael Semb Wever commented on CASSANDRA-18705:
(3) is done.
> Create release branch cassandra-5.0
> ---
>
> Key: CASSANDRA-18705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18705
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code:java}
> git switch -c cassandra-5.0 trunk
> git push --set-upstream origin cassandra-5.0
> {code}
> 2. Bump trunk's version
> {code:java}
> git switch trunk
> # increment version to 5.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
> circleci and in-tree scripts)
> -
> [https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96]
> - [https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374]
> - [https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85]
> 3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1` to
> jira versions
> (no existing tickets will be changed - assignees need to change appropriate
> bugs from 5.x to what is appropriate…)
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> [https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51]
> 6. Add dtest version and upgrade paths
> -
> [https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py]
> -
> [https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41]
> 7. Update how_to_commit documentation
> [https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc]
> 8. Update website CI to trigger off cassandra-5.0 builds
> -
> [https://github.com/apache/cassandra-builds/commit/1fc9b5ee71dc37e1145f276ead5c680c6b3fe3db]
--
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
[jira] [Commented] (CASSANDRA-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752803#comment-17752803
]
Maxwell Guo commented on CASSANDRA-18534:
-
So variation seems a little unclear to me. For example, for bti-fast and
bti-small, what are the specific meanings of fast and small for sstable or for
tables?
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
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
[jira] [Comment Edited] (CASSANDRA-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752803#comment-17752803
]
Maxwell Guo edited comment on CASSANDRA-18534 at 8/10/23 1:17 PM:
--
So variation seems a little unclear to me. For example, for bti-fast and
bti-small, what are the specific meanings of fast and small for sstable or for
tables? [~blambov]
was (Author: maxwellguo):
So variation seems a little unclear to me. For example, for bti-fast and
bti-small, what are the specific meanings of fast and small for sstable or for
tables?
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
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
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Severity: Normal (was: Critical)
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Severity: Normal (was: Critical)
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Severity: Critical (was: Normal)
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Urgent
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Severity: Critical (was: Normal)
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Urgent
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18740:
--
Status: Ready to Commit (was: Review In Progress)
j17
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2877/workflows/ab3db145-8458-4110-8c37-0de0b3871807
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
> warning: non-varargs call of varargs method with inexact argument type for
> last p
[jira] [Updated] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18740:
--
Reviewers: Brandon Williams
Status: Review In Progress (was: Needs Committer)
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey
[jira] [Commented] (CASSANDRA-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752790#comment-17752790
]
Branimir Lambov commented on CASSANDRA-18534:
-
No, any alphanumeric string chosen by the user. They should be able to specify
any number of configurations they want for any of the formats.
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
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
[jira] [Created] (CASSANDRA-18741) Some unit tests create a heap dump each time
Brandon Williams created CASSANDRA-18741: Summary: Some unit tests create a heap dump each time Key: CASSANDRA-18741 URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: Brandon Williams I noticed this by running out of space while working on CASSANDRA-18706. Something must be calling HeaupUtils.maybeCreateHeapDump because the build/test directory is littered with pid-epoch.hprof files despite the tests not crashing. I checked a couple other random tests, RandomSchemaTest also generates a dump but KeywordSplitTest does not. This behavior does not occur on 4.1. -- 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
[jira] [Updated] (CASSANDRA-18741) Some unit tests create a heap dump each time
[ https://issues.apache.org/jira/browse/CASSANDRA-18741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18741: - Bug Category: Parent values: Correctness(12982) Complexity: Normal Discovered By: User Report Fix Version/s: 5.x Severity: Normal Status: Open (was: Triage Needed) > Some unit tests create a heap dump each time > > > Key: CASSANDRA-18741 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18741 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.x > > > I noticed this by running out of space while working on CASSANDRA-18706. > Something must be calling HeaupUtils.maybeCreateHeapDump because the > build/test directory is littered with pid-epoch.hprof files > despite the tests not crashing. I checked a couple other random tests, > RandomSchemaTest also generates a dump but KeywordSplitTest does not. > This behavior does not occur on 4.1. -- 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
[jira] [Commented] (CASSANDRA-18705) Create release branch cassandra-5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-18705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752746#comment-17752746
]
Brandon Williams commented on CASSANDRA-18705:
--
bq. can you review the 5.0, trunk, dtest patches please.
Those look good, +1.
bq. all failures also exist in trunk, or are known flakies.
I'm not certain that's true for the upgrade failures aside from
test_negative_timestamp?
> Create release branch cassandra-5.0
> ---
>
> Key: CASSANDRA-18705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18705
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code:java}
> git switch -c cassandra-5.0 trunk
> git push --set-upstream origin cassandra-5.0
> {code}
> 2. Bump trunk's version
> {code:java}
> git switch trunk
> # increment version to 5.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
> circleci and in-tree scripts)
> -
> [https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96]
> - [https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374]
> - [https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85]
> 3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1` to
> jira versions
> (no existing tickets will be changed - assignees need to change appropriate
> bugs from 5.x to what is appropriate…)
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> [https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51]
> 6. Add dtest version and upgrade paths
> -
> [https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py]
> -
> [https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41]
> 7. Update how_to_commit documentation
> [https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc]
> 8. Update website CI to trigger off cassandra-5.0 builds
> -
> [https://github.com/apache/cassandra-builds/commit/1fc9b5ee71dc37e1145f276ead5c680c6b3fe3db]
--
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
[jira] [Commented] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752743#comment-17752743
]
Brandon Williams commented on CASSANDRA-18740:
--
Ah, thanks for this! +1
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expe
[jira] [Updated] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18740:
--
Status: Needs Committer (was: Patch Available)
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac]
[jira] [Updated] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18740:
--
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra/pull/2567
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac]
[jira] [Updated] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18740:
--
Bug Category: Parent values: Code(13163)
Complexity: Low Hanging Fruit
Discovered By: Code Inspection
Fix Version/s: 5.x
Severity: Low
Status: Open (was: Triage Needed)
> Fix compilation warning in RandomSchemaTest
> ---
>
> Key: CASSANDRA-18740
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>
> There are compilation warning for RandomSchemaTest and it just pollutes the
> ant build log unnecessarily. We should just fix it. The fix is about casting
> the objects to execute method to (Object[]).
> {code}
> _build-test:
> [javac] Compiling 1874 source files to
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Processing compiler hints annotations
> [javac] Note: Writing compiler command file at META-INF/hotspot_compiler
> [javac] Note: Done processing compiler hints annotations
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] execute(insertStmt, expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRowsNet(executeNet(selectStmt, rowKey),
> expected);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(selectStmt, rowKey),
> expected);
> [javac]^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [javac] assertRows(execute(tokenStmt, partitionKeys),
> partitionKeys);
> [javac] ^
> [javac] cast to Object for a varargs call
> [javac] cast to Object[] for a non-varargs call and to suppress this
> warning
> [javac]
> /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> [jav
[jira] [Created] (CASSANDRA-18740) Fix compilation warning in RandomSchemaTest
Stefan Miklosovic created CASSANDRA-18740:
-
Summary: Fix compilation warning in RandomSchemaTest
Key: CASSANDRA-18740
URL: https://issues.apache.org/jira/browse/CASSANDRA-18740
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Stefan Miklosovic
Assignee: Stefan Miklosovic
There are compilation warning for RandomSchemaTest and it just pollutes the ant
build log unnecessarily. We should just fix it. The fix is about casting the
objects to execute method to (Object[]).
{code}
_build-test:
[javac] Compiling 1874 source files to
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/build/test/classes
[javac] Note: Processing compiler hints annotations
[javac] Note: Processing compiler hints annotations
[javac] Note: Processing compiler hints annotations
[javac] Note: Writing compiler command file at META-INF/hotspot_compiler
[javac] Note: Done processing compiler hints annotations
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:131:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] execute(insertStmt, expected);
[javac] ^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:133:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] assertRows(execute(selectStmt, rowKey),
expected);
[javac]^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:134:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] assertRows(execute(tokenStmt, partitionKeys),
partitionKeys);
[javac] ^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:135:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] assertRowsNet(executeNet(selectStmt, rowKey),
expected);
[javac] ^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:140:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] assertRows(execute(selectStmt, rowKey),
expected);
[javac]^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:141:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] assertRows(execute(tokenStmt, partitionKeys),
partitionKeys);
[javac] ^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
[javac]
/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-5.0/test/unit/org/apache/cassandra/cql3/RandomSchemaTest.java:142:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
[javac] assertRowsNet(executeNet(selectStmt, rowKey),
expected);
[javac] ^
[javac] cast to Object for a varargs call
[javac] cast to Object[] for a non-varargs call and to suppress this
warning
{code}
--
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
[jira] [Commented] (CASSANDRA-18534) Make sstable format configurable per table
[
https://issues.apache.org/jira/browse/CASSANDRA-18534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752696#comment-17752696
]
Maxwell Guo commented on CASSANDRA-18534:
-
what does in the - stand for ? the
max_version of the sstable ? [~blambov]
> Make sstable format configurable per table
> --
>
> Key: CASSANDRA-18534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18534
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
>Reporter: Branimir Lambov
>Assignee: Maxwell Guo
>Priority: Normal
> Fix For: 5.x
>
>
> Some SSTable format settings need to be configurable per table for better
> efficiency. This includes:
> - {{row_index_granularity}}
> - {{bloom_filter_fp_chance}}
> - {{crc_check_chance}}
> - {{min/max_index_interval}}
> Some of these are currently configurable using direct properties of tables.
> Having them as format properties makes better sense and should also support
> specifying useable combinations of settings, e.g.
> {code:java}
> CREATE TABLE ... WITH sstable_format = "bti-fast";
> CREATE TABLE ... WITH sstable_format = "bti-small";
> {code}
> where {{bti-fast}} and {{bti-small}} can be defined in {{cassandra.yaml}}
> e.g. as
> {code:java}
> sstable.format.options:
> - bti-fast:
> row_index_granularity: 1kiB
> bloom_filter_fp_chance: 0.01
> - bti-small:
> row_index_granularity: 32kiB
> bloom_filter_fp_chance: 0.1
> {code}
--
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
[cassandra-website] branch asf-staging updated (af0077269 -> 21fb44509)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard af0077269 generate docs for f02aa10d new 21fb44509 generate docs for f02aa10d This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (af0077269) \ N -- N -- N refs/heads/asf-staging (21fb44509) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4852435 -> 4852435 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
[
https://issues.apache.org/jira/browse/CASSANDRA-17163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17163:
---
Resolution: Duplicate
Status: Resolved (was: Open)
> High CAS failures in MemtablePool.SubPool.tryAllocate
> -
>
> Key: CASSANDRA-17163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle
> a high amount of writes we are seeing some high contentions on
> {{MemtablePool.SubPool.tryAllocate}}.
> {code}"MutationStage-561" #5457 daemon prio=5 os_prio=0
> tid=0x7f35dd3cfa50 nid=0x1407a runnable [0x7f2357fd5000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
> at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
> at
> org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
> at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
> at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
> at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
> at
> org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
> at
> org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
> Source)
> at
> org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
> at
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {code}
> This issue is similar to CASSANDRA-15922.
--
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
[jira] [Commented] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752679#comment-17752679
]
Claude Warren commented on CASSANDRA-18739:
---
Dang. I accidentally deleted my earlier question.
A quick visual review indicates that it probably will.
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Commented] (CASSANDRA-18705) Create release branch cassandra-5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-18705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752677#comment-17752677
]
Michael Semb Wever commented on CASSANDRA-18705:
(7) is already being tackled by CASSANDRA-18738
> Create release branch cassandra-5.0
> ---
>
> Key: CASSANDRA-18705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18705
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code}
> git switch -c cassandra-5.0 trunk
> git push --set-upstream origin cassandra-5.0
> {code}
> 2. Bump trunk's version
> {code}
> git switch trunk
> # increment version to 5.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
> circleci and in-tree scripts)
> -
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>
> -
> https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
> - https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85
> 3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1.x`
> to jira versions
> (no existing tickets will be changed - assignees need to change appropriate
> bugs from 5.x to what is appropriate…)
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
> -
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
> -
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
> 8. Update website CI to trigger off cassandra-5.0 builds
> -
> https://github.com/apache/cassandra-builds/commit/1fc9b5ee71dc37e1145f276ead5c680c6b3fe3db
--
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
[jira] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[ https://issues.apache.org/jira/browse/CASSANDRA-18739 ]
Claude Warren deleted comment on CASSANDRA-18739:
---
was (Author: claudenw):
I did not look in depth into the trunk issues but I saw that Views and Tables
now require userfunctions in their constructors. Do you know if your change
work in that case as well?
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18705) Create release branch cassandra-5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-18705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18705:
---
Description:
Figure out what needs to be done beyond the following…
1. Create release branch
{code:java}
git switch -c cassandra-5.0 trunk
git push --set-upstream origin cassandra-5.0
{code}
2. Bump trunk's version
{code:java}
git switch trunk
# increment version to 5.1
edit build.xml debian/changelog CHANGES.txt NEWS.txt
{code}
2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
circleci and in-tree scripts)
-
[https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96]
- [https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374]
- [https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85]
3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1` to
jira versions
(no existing tickets will be changed - assignees need to change appropriate
bugs from 5.x to what is appropriate…)
4. Update docker images to include cassandra-5.0
(Docker images also need to be deployed)
5. Add pipeline to ci-cassandra
[https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51]
6. Add dtest version and upgrade paths
-
[https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py]
-
[https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41]
7. Update how_to_commit documentation
[https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc]
8. Update website CI to trigger off cassandra-5.0 builds
-
[https://github.com/apache/cassandra-builds/commit/1fc9b5ee71dc37e1145f276ead5c680c6b3fe3db]
was:
Figure out what needs to be done beyond the following…
1. Create release branch
{code}
git switch -c cassandra-5.0 trunk
git push --set-upstream origin cassandra-5.0
{code}
2. Bump trunk's version
{code}
git switch trunk
# increment version to 5.1
edit build.xml debian/changelog CHANGES.txt NEWS.txt
{code}
2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
circleci and in-tree scripts)
-
https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
-
https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
- https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85
3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1.x` to
jira versions
(no existing tickets will be changed - assignees need to change appropriate
bugs from 5.x to what is appropriate…)
4. Update docker images to include cassandra-5.0
(Docker images also need to be deployed)
5. Add pipeline to ci-cassandra
https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
6. Add dtest version and upgrade paths
-
https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
-
https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
7. Update how_to_commit documentation
https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
8. Update website CI to trigger off cassandra-5.0 builds
-
https://github.com/apache/cassandra-builds/commit/1fc9b5ee71dc37e1145f276ead5c680c6b3fe3db
> Create release branch cassandra-5.0
> ---
>
> Key: CASSANDRA-18705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18705
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code:java}
> git switch -c cassandra-5.0 trunk
> git push --set-upstream origin cassandra-5.0
> {code}
> 2. Bump trunk's version
> {code:java}
> git switch trunk
> # increment version to 5.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 2a. Update jvm-dtest supported upgrade paths, and dtest jar generation (both
> circleci and in-tree scripts)
> -
> [https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96]
> - [https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374]
> - [https://github.com/apache/cassandra/blob/trunk/.build/run-tests.sh#L85]
> 3. Add `5.0-alpha`, `5.0-alpha1`, `5.0-beta`, `5.0-rc`, `5.0.x` and `5.1` to
> jira versions
> (no existing tickets will be changed - assignees need to change approp
[jira] [Commented] (CASSANDRA-18738) Update the How to Commit page after CASSANDRA-18618
[ https://issues.apache.org/jira/browse/CASSANDRA-18738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752676#comment-17752676 ] Michael Semb Wever commented on CASSANDRA-18738: +1 one small optional comment added in the PR wrt the superfluous use of `build-test` > Update the How to Commit page after CASSANDRA-18618 > --- > > Key: CASSANDRA-18738 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18738 > Project: Cassandra > Issue Type: Task > Components: Legacy/Documentation and Website >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > In CASSANDRA-18618, checks like rat and checkstyle were moved to a separate > ant task - "check". > We need to update our How to commit page that on branches Cassandra-5.0 + we > need to run now ant realclean && ant jar build-test check pre-commit. While > on that, we already have the cassandra-5.0 branch, so that we can add that > too. -- 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
[jira] [Comment Edited] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752669#comment-17752669
]
Stefan Miklosovic edited comment on CASSANDRA-18739 at 8/10/23 7:45 AM:
I am not sure. Would you mind to check that?
But, presumably, I think that should work too, we are just passing a name of a
keyspace to UDFContextImpl and then udtType resolution is done upon querying a
table / view and again, by that time, KeyspaceMetadata is there as schema is
fully initialized.
was (Author: smiklosovic):
I am not sure. Would you mind to check that?
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available
[jira] [Commented] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752669#comment-17752669
]
Stefan Miklosovic commented on CASSANDRA-18739:
---
I am not sure. Would you mind to check that?
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Bug Category: Parent values: Degradation(12984)
Complexity: Normal
Discovered By: Adhoc Test
Reviewers: Stefan Miklosovic
Severity: Normal
Status: Open (was: Triage Needed)
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additio
[jira] [Commented] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752668#comment-17752668
]
Claude Warren commented on CASSANDRA-18739:
---
I did not look in depth into the trunk issues but I saw that Views and Tables
now require userfunctions in their constructors. Do you know if your change
work in that case as well?
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache
[jira] [Commented] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752667#comment-17752667
]
Stefan Miklosovic commented on CASSANDRA-18739:
---
Hi [~claude], thanks for this!
I looked into it and this might be a solution. I restarted a node and it just
worked ...
The approach I took is that we do not need KeyspaceMetadata (which is null)
upon function's creation. That is not necessary. We just need that stuff in
runtime when you do queries etc and by that time it is already initialized.
(1) https://github.com/apache/cassandra/pull/2566/files
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the Keyspac
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Description:
UDFs fail to reload properly after a rolling restart.
h3. *Symptom:*
NPE thrown when used after restart.
h3. *Steps to recreate:*
# Create a cluster as per cql file
# Populate the cluster with data.cql.
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect min and max values for cities.
# Performing a rolling restart on one server.
# When the server is back up
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect: error result with NPE message.
{*}Analysis{*}:
During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
when a keyspace with a UDF is loaded the SchemaKeyspace method
createUDFFromRow() is called, this in turn calls UDFunction.create() which
eventually calls back to UDFunction constructor where the
Schema.instance.getKeyspaceMetadata() is called with the keyspace for the UDF
name as the argument. However, the keyspace for the UDF name is being
constructed and is not yet in the instance so the method returns null for the
KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
Later when the UDF method is called, if there is a need to call a method on the
keyspaceMetadata, such as udfContext.newUDTValue() where the implementation
uses keyspaceMetadata.types, a null pointer is thrown.
I have verified this affects version 4.0, 4.1 and trunk. I have not verified
3.x but I suspect it is the same there.
I modified UDFunction constructor to assert that the metadata was not null and
received the following stack trace
ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
encountered during startup
java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
at
org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
at
org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
at
org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
at
org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
{{*Possible solution:*}}
*Version 4.x*
Create a KeyspaceMetadata.Builder class that uses accepts the types, tables and
views but uses a builder for the functions.
Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
that the function builder keyspaceMetadata value can be set correctly during
construction of the KeyspaceMetadata.
Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
KeyspaceMetadata.Builder.
*Version 5.x*
Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
builders for Views and Tables because the functions necessary to construct
those objects will not be available until the KeyspaceMetadata.Builder
constructs it.
was:
UDFs fail to reload properly after a rolling restart.
h3. *Symptom:*
NPE thrown when used after restart.
h3. *Steps to recreate:*
# Create a cluster as per cql file
# Populate the cluster with data.cql.
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect min and max values for cities.
# Performing a rolling restart on one server.
# When the server is back up
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect: error result with NPE message.
{*}Analysis{*}:
During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
when a keyspace with a UDF is loaded the SchemaKeyspace method
createUDFFromRow() is called, this in turn calls UDFunction.create() which
eventually calls back to UDFunction constructor where the
Schema.instance.getKeySpaceMetadata() is called with the keyspace for the UDF
name as the argument. However, the keyspace for the UDF name is being
constructed and is not yet in the instance so the method returns null for the
KeyspaceMet
[jira] [Updated] (CASSANDRA-18739) UDF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Summary: UDF functions fail to load on rolling restart (was: USF functions
fail to load on rolling restart)
> UDF functions fail to load on rolling restart
> -
>
> Key: CASSANDRA-18739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18739
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDF
>Reporter: Claude Warren
>Assignee: Claude Warren
>Priority: Normal
> Attachments: udf_error.cql, udf_error_data.cql
>
>
> UDFs fail to reload properly after a rolling restart.
> h3. *Symptom:*
> NPE thrown when used after restart.
> h3. *Steps to recreate:*
> # Create a cluster as per cql file
> # Populate the cluster with data.cql.
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect min and max values for cities.
> # Performing a rolling restart on one server.
> # When the server is back up
> # Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
> # expect: error result with NPE message.
> {*}Analysis{*}:
> During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
> when a keyspace with a UDF is loaded the SchemaKeyspace method
> createUDFFromRow() is called, this in turn calls UDFunction.create() which
> eventually calls back to UDFunction constructor where the
> Schema.instance.getKeySpaceMetadata() is called with the keyspace for the UDF
> name as the argument. However, the keyspace for the UDF name is being
> constructed and is not yet in the instance so the method returns null for the
> KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
> Later when the UDF method is called, if there is a need to call a method on
> the keyspaceMetadata, such as udfContext.newUDTValue() where the
> implementation uses keyspaceMetadata.types, a null pointer is thrown.
> I have verified this affects version 4.0, 4.1 and trunk. I have not verified
> 3.x but I suspect it is the same there.
> I modified UDFunction constructor to assert that the metadata was not null
> and received the following stack trace
> ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
> encountered during startup
> java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
> at
> org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
> at
> org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
> at
> org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
> at
> org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
> at
> org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
> at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
>
> {{*Possible solution:*}}
> *Version 4.x*
> Create a KeyspaceMetadata.Builder class that uses accepts the types, tables
> and views but uses a builder for the functions.
> Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
> that the function builder keyspaceMetadata value can be set correctly during
> construction of the KeyspaceMetadata.
> Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
> KeyspaceMetadata.Builder.
>
> *Version 5.x*
> Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
> builders for Views and Tables because the functions necessary to construct
> those objects will not be available until the KeyspaceMetadata.Builder
> constructs it.
>
--
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
[jira] [Updated] (CASSANDRA-18739) USF functions fail to load on rolling restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18739:
--
Description:
UDFs fail to reload properly after a rolling restart.
h3. *Symptom:*
NPE thrown when used after restart.
h3. *Steps to recreate:*
# Create a cluster as per cql file
# Populate the cluster with data.cql.
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect min and max values for cities.
# Performing a rolling restart on one server.
# When the server is back up
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect: error result with NPE message.
{*}Analysis{*}:
During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
when a keyspace with a UDF is loaded the SchemaKeyspace method
createUDFFromRow() is called, this in turn calls UDFunction.create() which
eventually calls back to UDFunction constructor where the
Schema.instance.getKeySpaceMetadata() is called with the keyspace for the UDF
name as the argument. However, the keyspace for the UDF name is being
constructed and is not yet in the instance so the method returns null for the
KeyspaceMetadata. That null KeyspaceMetadata is then used in the udfContext.
Later when the UDF method is called, if there is a need to call a method on the
keyspaceMetadata, such as udfContext.newUDTValue() where the implementation
uses keyspaceMetadata.types, a null pointer is thrown.
I have verified this affects version 4.0, 4.1 and trunk. I have not verified
3.x but I suspect it is the same there.
I modified UDFunction constructor to assert that the metadata was not null and
received the following stack trace
ERROR [main] 2023-08-09 11:44:46,408 CassandraDaemon.java:911 - Exception
encountered during startup
java.lang.AssertionError: No metadata for temperatures.city_measurements_sfunc
at
org.apache.cassandra.cql3.functions.UDFunction.(UDFunction.java:240)
at
org.apache.cassandra.cql3.functions.JavaBasedUDFunction.(JavaBasedUDFunction.java:195)
at
org.apache.cassandra.cql3.functions.UDFunction.create(UDFunction.java:276)
at
org.apache.cassandra.schema.SchemaKeyspace.createUDFFromRow(SchemaKeyspace.java:1182)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchUDFs(SchemaKeyspace.java:1131)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchFunctions(SchemaKeyspace.java:1119)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:859)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
at
org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:287)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
{{*Possible solution:*}}
*Version 4.x*
Create a KeyspaceMetadata.Builder class that uses accepts the types, tables and
views but uses a builder for the functions.
Add a KeyspaceMetadata constructor to accept the KeyspaceMetadata.Builder so
that the function builder keyspaceMetadata value can be set correctly during
construction of the KeyspaceMetadata.
Modify SchemaKeyspace.fetchKeyspace(string) so that it uses the
KeyspaceMetadata.Builder.
*Version 5.x*
Similar to 4.x except that the KeyspaceMetadata.Builder will have to have
builders for Views and Tables because the functions necessary to construct
those objects will not be available until the KeyspaceMetadata.Builder
constructs it.
was:
UDFs fail to reload properly after a rolling restart.
h3. *Symptom:*
NPE thrown when used after restart.
h3. *Steps to recreate:*
# Create a cluster as per cql file
# Populate the cluster with data.cql.
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect min and max values for cities.
# Performing a rolling restart on one server.
# When the server is back up
# Execute SELECT city_measurements(city, measurement, 16.5) AS m FROM current
# expect: error result with NPE message.
{*}Analysis{*}:
During system restart the SchemaKeyspace.fetchNonSystemKeyspaces() is called,
when a keyspace with a UDF is loaded the ShcemaKeyspace method
createUDFFromRow() is called, this in tern calls UDFunction.create() which
eventually calls back to UDFunction constructor where the
Schema.instance.getKeySpaceMetadata() is called with the keyspace for the UDF
name as the argument. However, the keyspace for the UDF name is being
constructed and is not yet in the instance so the method returns null for the
KeyspaceM
[jira] [Commented] (CASSANDRA-18585) Alter Type does not validate changes like Create Type does
[
https://issues.apache.org/jira/browse/CASSANDRA-18585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752646#comment-17752646
]
Stefan Miklosovic commented on CASSANDRA-18585:
---
Hi [~urbanchef], kindly asking if there is any progress here.
> Alter Type does not validate changes like Create Type does
> --
>
> Key: CASSANDRA-18585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18585
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: David Capwell
>Assignee: Roman Mushchinski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Create Type attempts to block undesired field types, but this validation is
> not cared over to Alter Type Add Field; which allows you to add
> unexpected/desired types
> {code}
> Assertions.assertThatThrownBy(() -> createType("CREATE TYPE %s (f
> counter)")).hasRootCauseMessage("A user type cannot contain counters");
> String type = createType(KEYSPACE, "CREATE TYPE %s (a int)");
> schemaChange(String.format("ALTER TYPE %s.%s ADD f counter", KEYSPACE, type));
> UserType udt =
> Keyspace.open(KEYSPACE).getMetadata().types.get(UTF8Type.instance.decompose(type)).get();
> logger.warn("UDT: {}", udt);
> {code}
> {code}
> UDT:
> org.apache.cassandra.db.marshal.UserType(cql_test_keyspace,747970655f3031,61:org.apache.cassandra.db.marshal.Int32Type,66:org.apache.cassandra.db.marshal.CounterColumnType)
> {code}
--
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
