[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16895:
Fix Version/s: 5.0
(was: 5.x)
> Build with Java 17
> --
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Epic
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0
>
>
> This ticket is intended to group all issues found to support Java 17 in the
> future.
> Upgrade steps:
> * [Dependencies
> |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
> be updated (not all but at least those that require an update in order to
> work with Java 17)
> * More encapsulated JDK internal APIs. Some of the issues might be solved
> with the dependencies updates
> * Currently trunk compiles if we remove the Nashorn dependency (ant script
> tag, used for the test environment; UDFs) . The oracle recommendation to use
> Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
> we will opt in for graal-sdk licensed under UPL
> * All tests to be cleaned
> * CI environment to be setup
> *NOTE:* GC tuning, performance testing were never agreed to be part of this
> ticket.
> Below is a snapshot of current CI failures with JDK17, it will be updated on
> a regular basis with a date of update
> *July 15th 2023*
> || ||Failing Test Classes||Ticket Numbers||
> | |_Python DTests_| |
> |1|-test_sjk-|CASSANDRA-18343|
> | |_Java Ditributed Tests_| |
> |1-6|-org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all
> tests,-
> -org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all
> tests,-
> -org.apache.cassandra.distributed.test.IPMembershipTest - both tests,-
> -org.apache.cassandra.distributed.test.MixedModeFuzzTest,-
> -org.apache.cassandra.distributed.test.ReprepareFuzzTest,-
> -org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest-|CASSANDRA-16304|
> |7,8|-org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
> - all tests-
> -org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all
> tests-|Both tests suffer from CASSANDRA-18180 -
> *ready to commit; blocked on being ready to drop JDK8*
>
> fwiw, using the CASSANDRA-18180 branch, only the
> negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests.
>
> EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed
> to negotiate (netty complains about certificate_unknown). Changes in JDK17
> config to be checked - done
>
> EDIT2: CASSANDRA-18540|
> |-9-|-org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest
> - 2 tests-|CASSANDRA-18180 ready to commit; blocked on being ready to drop
> JDK8|
> | |_Unit Tests_| |
> |1|-org.apache.cassandra.repair.RepairJobTest - 1 test-|CASSANDRA-18329|
> |2|-org.apache.cassandra.security.SSLFactoryTest - all tests-|CASSANDRA-17992|
> |3,4|-org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,-
> -org.apache.cassandra.utils.concurrent.RefCountedTest-|CASSANDRA-18329|
> |5,6|-org.apache.cassandra.cql3.validation.entities.UFJavaTest,-
> -org.apache.cassandra.cql3.validation.entities.UFSecurityTest-|CASSANDRA-18190;
> ready to commit; blocked on being ready to drop JDK8|
> |7|-org.apache.cassandra.cql3.EmptyValuesTest-|CASSANDRA-18436|
> |8|{-}org.apache.cassandra.transport.MessagePayloadTest{-}.jdk17-|CASSANDRA-18437|
> |9|-StandaloneSplitterWithCQLTesterTest/testSplittingMultipleSSTables-|CASSANDRA-18685|
> | |_Burn tests_| |
> |1|-org.apache.cassandra.transport.DriverBurnTest.measureLargeV4WithCompression-|CASSANDRA-18570|
>
--
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-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Status: Review In Progress (was: Patch Available) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- 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-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Benjamin Lerer) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- 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-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Authors: Benjamin Lerer, Ekaterina Dimitrova (was: Ekaterina Dimitrova) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- 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-19534) unbounded queues in native transport requests lead to node instability
[
https://issues.apache.org/jira/browse/CASSANDRA-19534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848777#comment-17848777
]
Ekaterina Dimitrova commented on CASSANDRA-19534:
-
{quote}+1 LGTM
(dropped a couple more little cleanup nits in the PR)
{quote}
Does this mean this is ready to commit? :D I am excited as this is one of the
last two 5.0 rc blockers
> unbounded queues in native transport requests lead to node instability
> --
>
> Key: CASSANDRA-19534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19534
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jon Haddad
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Attachments: Scenario 1 - QUEUE + Backpressure.jpg, Scenario 1 -
> QUEUE.jpg, Scenario 1 - Stock.jpg, Scenario 2 - QUEUE + Backpressure.jpg,
> Scenario 2 - QUEUE.jpg, Scenario 2 - Stock.jpg, ci_summary.html,
> image-2024-05-03-16-08-10-101.png, screenshot-1.png, screenshot-2.png,
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png,
> screenshot-7.png, screenshot-8.png, screenshot-9.png
>
> Time Spent: 9h 50m
> Remaining Estimate: 0h
>
> When a node is under pressure, hundreds of thousands of requests can show up
> in the native transport queue, and it looks like it can take way longer to
> timeout than is configured. We should be shedding load much more
> aggressively and use a bounded queue for incoming work. This is extremely
> evident when we combine a resource consuming workload with a smaller one:
> Running 5.0 HEAD on a single node as of today:
> {noformat}
> # populate only
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --maxrlat 100 --populate
> 10m --rate 50k -n 1
> # workload 1 - larger reads
> easy-cass-stress run RandomPartitionAccess -p 100 -r 1
> --workload.rows=10 --workload.select=partition --rate 200 -d 1d
> # second workload - small reads
> easy-cass-stress run KeyValue -p 1m --rate 20k -r .5 -d 24h{noformat}
> It appears our results don't time out at the requested server time either:
>
> {noformat}
> Writes Reads
> Deletes Errors
> Count Latency (p99) 1min (req/s) | Count Latency (p99) 1min (req/s) |
> Count Latency (p99) 1min (req/s) | Count 1min (errors/s)
> 950286 70403.93 634.77 | 789524 70442.07 426.02 |
> 0 0 0 | 9580484 18980.45
> 952304 70567.62 640.1 | 791072 70634.34 428.36 |
> 0 0 0 | 9636658 18969.54
> 953146 70767.34 640.1 | 791400 70767.76 428.36 |
> 0 0 0 | 9695272 18969.54
> 956833 71171.28 623.14 | 794009 71175.6 412.79 |
> 0 0 0 | 9749377 19002.44
> 959627 71312.58 656.93 | 795703 71349.87 435.56 |
> 0 0 0 | 9804907 18943.11{noformat}
>
> After stopping the load test altogether, it took nearly a minute before the
> requests were no longer queued.
--
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-10715) Allow filtering on NULL
[
https://issues.apache.org/jira/browse/CASSANDRA-10715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-10715:
---
Assignee: Benjamin Lerer (was: Ekaterina Dimitrova)
> Allow filtering on NULL
> ---
>
> Key: CASSANDRA-10715
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10715
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: C* 3.0.0 | cqlsh | C# driver 3.0.0beta2 | Windows 2012 R2
>Reporter: Kishan Karunaratne
>Assignee: Benjamin Lerer
>Priority: Low
> Fix For: 5.x
>
> Attachments:
> 0001-Allow-null-values-in-filtered-searches-reuse-Operato.patch
>
>
> This is an issue I first noticed through the C# driver, but I was able to
> repro on cqlsh, leading me to believe this is a Cassandra bug.
> Given the following schema:
> {noformat}
> CREATE TABLE "TestKeySpace_4928dc892922"."coolMovies" (
> unique_movie_title text,
> movie_maker text,
> director text,
> list list,
> "mainGuy" text,
> "yearMade" int,
> PRIMARY KEY ((unique_movie_title, movie_maker), director)
> ) WITH CLUSTERING ORDER BY (director ASC)
> {noformat}
> Executing a SELECT with FILTERING on a non-PK column, using a NULL as the
> argument:
> {noformat}
> SELECT "mainGuy", "movie_maker", "unique_movie_title", "list", "director",
> "yearMade" FROM "coolMovies" WHERE "mainGuy" = null ALLOW FILTERING
> {noformat}
> returns a ReadFailure exception:
> {noformat}
> cqlsh:TestKeySpace_4c8f2cf8d5cc> SELECT "mainGuy", "movie_maker",
> "unique_movie_title", "list", "director", "yearMade" FROM "coolMovies" WHERE
> "mainGuy" = null ALLOW FILTERING;
> ←[0;1;31mTraceback (most recent call last):
> File "C:\Users\Kishan\.ccm\repository\3.0.0\bin\\cqlsh.py", line 1216, in
> perform_simple_statement
> result = future.result()
> File
> "C:\Users\Kishan\.ccm\repository\3.0.0\bin\..\lib\cassandra-driver-internal-only-3.0.0a3.post0-3f15725.zip\cassandra-driver-3.0.0a3.post0-3f15725\cassandra\cluster.py",
> line 3118, in result
> raise self._final_exception
> ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation
> failed - received 0 responses and 1 failures" info={'failures': 1,
> 'received_responses': 0, 'required_responses': 1, 'cons
> istency': 'ONE'}
> ←[0m
> {noformat}
> Cassandra log shows:
> {noformat}
> WARN [SharedPool-Worker-2] 2015-11-16 13:51:00,259
> AbstractTracingAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-2,10,main]: {}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.filter.RowFilter$SimpleExpression.isSatisfiedBy(RowFilter.java:581)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToRow(RowFilter.java:243)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.BaseRows.applyOne(BaseRows.java:95)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at org.apache.cassandra.db.transform.BaseRows.add(BaseRows.java:86)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.UnfilteredRows.add(UnfilteredRows.java:21)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.Transformation.add(Transformation.java:136)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.Transformation.apply(Transformation.java:102)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:233)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.filter.RowFilter$CQLFilter$1IsSatisfiedFilter.applyToPartition(RowFilter.java:227)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:76)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:293)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:128)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:123)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65)
> ~[apache-cassandra-3.0.0.jar:3.0.0]
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:288)
>
[jira] [Updated] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Status: Review In Progress (was: Patch Available)
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846108#comment-17846108 ] Ekaterina Dimitrova commented on CASSANDRA-18106: - bq. We weren't running dtest-upgrade-large tests at all, so there was no need for jdk switching. (We'd forgotten about the --intensive flag on upgrade tests.) Good catch bq. Are these tests really testing something that is persisted (serialised), i.e. something that happens in 3.0 that persists and isn't a problem until two major version later in 5.0 ? That sounds more like serialisation tests (that don't even need to be upgrade tests). bq. ccm still supports jdk switching with JAVAx_HOME env vars, so if we need to we can still introduce these vars carefully for just these particular tests found in dtest-upgrade-large. (i.e. there's no change to undo here, we're still moving forward to a cleaner place…) That sounds like a topic for a new ticket? We should also add the missing --intensive flag to CircleCI config, too. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- 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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846092#comment-17846092
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}From the comments it seems that both V3 and V4 will need to cross JDKs
{quote}
Not if we do not recommend that the JDK and Cassandra upgrade happen
simultaneously. Which we do not?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 5/13/24 9:59 PM:
--
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
bq. Without the JAVAx_HOME variables set they skip steps that involve C*
versions that require a different jdk.
So this was intentional and those are not skipped when run with other branches
was (Author: e.dimitrova):
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846089#comment-17846089
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}We do have tests that need to change jdks. The dtest-upgrade-large* test
types have tests like
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD
{quote}
I mentioned this back then, and if I remember correctly there was the argument
- we repeat test runs with the different branch upgrade test runs, we should
save resources?
If we consider change of jdks, we will be running the whole path when we run on
3.0, same on 3.11, same on 4.0, etc. Lots of repetition. Is this not an
argument anymore?
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0-alpha1, 5.0
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
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-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845318#comment-17845318
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
5.x, as this is a new feature it can only go to trunk. Updated the ticket fix
version
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
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-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19604:
Fix Version/s: 5.x
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Fix For: 5.x
>
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
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-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845139#comment-17845139
]
Ekaterina Dimitrova commented on CASSANDRA-19604:
-
Thank you, [~xvade]! I believe you and [~blerer] already discussed the next
steps, which I agree with. Please let me know if you have any questions or
concerns. Also, as a reminder, CASSANDRA-19341 is now committed, so you can
rebase your patch on the latest Cassandra trunk branch.
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19628:
Status: Ready to Commit (was: Changes Suggested)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845025#comment-17845025
]
Ekaterina Dimitrova commented on CASSANDRA-19628:
-
bq. How does that look?
That's great +1 (y)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845019#comment-17845019
]
Ekaterina Dimitrova edited comment on CASSANDRA-19628 at 5/9/24 2:57 PM:
-
I have a suggestion, what do you think if we just point to the instruction
in-tree? - https://github.com/apache/cassandra/blob/trunk/pylib/README.asc
That one looks more up to date, plus we do not need to maintain instructions
for those tests in two places. People often forget to update the website.
About the current suggestion if we decide to go with it:
Without those configs set correctly, some of the tests will fail, and these
commands are mentioned as a procedure for running all tests. Can we correct the
config?
Also, a side note: the instruction claims we still use nosetest.
People best bet is to use cassandra-cqlsh-tests.sh which is mentioned in the
in-tree README
was (Author: e.dimitrova):
I have a suggestion, what do you think if we just point to the instruction
in-tree? - https://github.com/apache/cassandra/blob/trunk/pylib/README.asc
That one looks more up to date, plus we do not need to maintain instructions
for those tests in two places. People often forget to update the website.
About the current suggestion if we decide to go with it:
Without those configs set correctly, some of the tests will fail, and these
commands are mentioned as a procedure for running all tests. Can we correct the
config?
Also, a side note: the instruction claims we still use nosetest.
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19628:
Status: Changes Suggested (was: Review In Progress)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845019#comment-17845019
]
Ekaterina Dimitrova commented on CASSANDRA-19628:
-
I have a suggestion, what do you think if we just point to the instruction
in-tree? - https://github.com/apache/cassandra/blob/trunk/pylib/README.asc
That one looks more up to date, plus we do not need to maintain instructions
for those tests in two places. People often forget to update the website.
About the current suggestion if we decide to go with it:
Without those configs set correctly, some of the tests will fail, and these
commands are mentioned as a procedure for running all tests. Can we correct the
config?
Also, a side note: the instruction claims we still use nosetest.
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19628) Correct testing instructions on the website
[
https://issues.apache.org/jira/browse/CASSANDRA-19628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19628:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Correct testing instructions on the website
> ---
>
> Key: CASSANDRA-19628
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19628
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Documentation and Website
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> At https://cassandra.apache.org/_/development/testing.html it says to issue
> these statements for cqlsh tests:
> {noformat}
> ccm updateconf "enable_user_defined_functions: true"
> ccm updateconf "enable_scripted_user_defined_functions: true"
> ccm updateconf "cdc_enabled: true"
> {noformat}
> But these actually break the configuration so it won't start.
--
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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844300#comment-17844300
]
Ekaterina Dimitrova edited comment on CASSANDRA-19341 at 5/7/24 1:47 PM:
-
[~smiklosovic], thank you for the ping and sorry for the noise, there were a
few empty lines removed by mistake in that test.
Ninja fixed to https://github.com/apache/cassandra-dtest.git
6dd7def9..1f81e1c9 trunk -> trunk
Tested the fixed cassandra-dtest trunk locally with all Cassandra branches 4.0+
was (Author: e.dimitrova):
[~smiklosovic], thank you for the ping and sorry for the noise, there were a
few empty lines removed by mistake in that test.
Ninja fixed to https://github.com/apache/cassandra-dtest.git
6dd7def9..1f81e1c9 trunk -> trunk
Tested the fixed branch locally on all branches 4.0+
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844300#comment-17844300
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
[~smiklosovic], thank you for the ping and sorry for the noise, there were a
few empty lines removed by mistake in that test.
Ninja fixed to https://github.com/apache/cassandra-dtest.git
6dd7def9..1f81e1c9 trunk -> trunk
Tested the fixed branch locally on all branches 4.0+
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843844#comment-17843844
]
Ekaterina Dimitrova edited comment on CASSANDRA-19341 at 5/6/24 8:50 PM:
-
This was the latest CI run:
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436/jobs/11079/tests
- environmental, seen before. Considering the same tests passed with 11, we
did not see the need to rerun that job
The rest are known issues:
test_counter_node_down - CASSANDRA-19346
test_change_durable_writes - CASSANDRA-19601
test_cleanup - CASSANDRA-18908
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
New unit tests were not run in a loop as they are pretty deterministic.
Those that changed were changing primarily error messages text.
Thank you everyone!
was (Author: e.dimitrova):
This was the latest CI run:
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436/jobs/11079/tests
- environmental, seen before. Considering the same tests passed with 11, we
did not see the need to rerun that job
The rest are known issues:
test_counter_node_down - CASSANDRA-19346
test_change_durable_writes - CASSANDRA-19601
test_cleanup - CASSANDRA-18908
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
New unit tests were not run in a loop as they are pretty deterministic.
Thank you everyone!
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32.5h
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Description: CASSANDRA-19341 added ColumnsExpression in restrictions. This ticket's target is to extend the kinds of ColumnsExpression and use them in conditions, too. Also, it should add a few other simplifications around ColumnCondition, which were suggested by [~blerer] was: CASSANDRA-19341 added ColumnsExpression in restrictions. This ticket's target is to extend the kinds of ColumnsExpression and use them in conditions, too. Also, it should add a few other simplifications around ColumnCondition, suggested by [~blerer] > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, which > were suggested by [~blerer] -- 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-19620) Refactor ColumnCondition post CASSANDRA-19341
[ https://issues.apache.org/jira/browse/CASSANDRA-19620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19620: Change Category: Code Clarity Complexity: Normal Component/s: CQL/Interpreter Fix Version/s: 5.x Status: Open (was: Triage Needed) > Refactor ColumnCondition post CASSANDRA-19341 > - > > Key: CASSANDRA-19620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > CASSANDRA-19341 added ColumnsExpression in restrictions. > This ticket's target is to extend the kinds of ColumnsExpression and use them > in conditions, too. > Also, it should add a few other simplifications around ColumnCondition, > suggested by [~blerer] -- 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-19620) Refactor ColumnCondition post CASSANDRA-19341
Ekaterina Dimitrova created CASSANDRA-19620: --- Summary: Refactor ColumnCondition post CASSANDRA-19341 Key: CASSANDRA-19620 URL: https://issues.apache.org/jira/browse/CASSANDRA-19620 Project: Cassandra Issue Type: Improvement Reporter: Ekaterina Dimitrova Assignee: Ekaterina Dimitrova CASSANDRA-19341 added ColumnsExpression in restrictions. This ticket's target is to extend the kinds of ColumnsExpression and use them in conditions, too. Also, it should add a few other simplifications around ColumnCondition, suggested by [~blerer] -- 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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843844#comment-17843844
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
This was the latest CI run:
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436
https://app.circleci.com/pipelines/github/blerer/cassandra/401/workflows/befac1e9-d706-436c-aa18-bb5141ec4436/jobs/11079/tests
- environmental, seen before. Considering the same tests passed with 11, we
did not see the need to rerun that job
The rest are known issues:
test_counter_node_down - CASSANDRA-19346
test_change_durable_writes - CASSANDRA-19601
test_cleanup - CASSANDRA-18908
org.apache.cassandra.simulator.test.HarrySimulatorTest - CASSANDRA-19279
New unit tests were not run in a loop as they are pretty deterministic.
Thank you everyone!
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32.5h
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843725#comment-17843725
]
Ekaterina Dimitrova commented on CASSANDRA-19619:
-
[~mmuzaf], this ticket is marked 5.0-rc blocker? Was this a mistake or is it a
blocker?
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19614) Add java version to prepare_release.sh human check step
[ https://issues.apache.org/jira/browse/CASSANDRA-19614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843023#comment-17843023 ] Ekaterina Dimitrova commented on CASSANDRA-19614: - +1 > Add java version to prepare_release.sh human check step > --- > > Key: CASSANDRA-19614 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19614 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > With the many versions of java one may need to float these days, it would be > nice for prepare_release.sh to show the version you are using when it asks > the "Is this what you want?" question showing the latest commit, that way > there is a chance to correct things before it tags. -- 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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842740#comment-17842740
]
Ekaterina Dimitrova edited comment on CASSANDRA-19341 at 5/1/24 6:36 PM:
-
The simulator failures are known from
CASSANDRA-19279 and CASSANDRA-19280
I also checked the rest of the tests yesterday, and I found/filed tickets for
all of them (except testSimpleSnapshot, which fails locally for me with the
patch). I can write a full report for the failures <-> tickets when we finish.
was (Author: e.dimitrova):
The simulator failures are known from
CASSANDRA-19279 and CASSANDRA-19280
I also checked the rest of the tests yesterday, and I found/filed tickets for
all of them. I can write down a full report failures <-> tickets when we are
done.
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842740#comment-17842740
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
The simulator failures are known from
CASSANDRA-19279 and CASSANDRA-19280
I also checked the rest of the tests yesterday, and I found/filed tickets for
all of them. I can write down a full report failures <-> tickets when we are
done.
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842737#comment-17842737
]
Ekaterina Dimitrova commented on CASSANDRA-19341:
-
FYI, testSimpleSnapshot is failing with this patch, and it is under
investigation.
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 22h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-17298) Test Failure: org.apache.cassandra.cql3.MemtableSizeTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842731#comment-17842731
]
Ekaterina Dimitrova commented on CASSANDRA-17298:
-
I don't know about the local error you get, but this is about the one you see
in CI:
4.0 and 4.1 use the old version of jamm where there were issues with the
crawling, so I am not surprised measureDeep hit closed module. This cannot be
related to your patch. It is jamm issue.
> Test Failure: org.apache.cassandra.cql3.MemtableSizeTest
>
>
> Key: CASSANDRA-17298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17298
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> [https://ci-cassandra.apache.org/job/Cassandra-4.0/313/testReport/org.apache.cassandra.cql3/MemtableSizeTest/testTruncationReleasesLogSpace_2/]
> Failed 4 times in the last 30 runs. Flakiness: 27%, Stability: 86%
> Error Message
> Expected heap usage close to 49.930MiB, got 41.542MiB.
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Expected heap usage close to 49.930MiB,
> got 41.542MiB.
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testSize(MemtableSizeTest.java:130)
> at org.apache.cassandra.Util.runCatchingAssertionError(Util.java:644)
> at org.apache.cassandra.Util.flakyTest(Util.java:669)
> at
> org.apache.cassandra.cql3.MemtableSizeTest.testTruncationReleasesLogSpace(MemtableSizeTest.java:61)
> 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)
> {code}
> *UPDATE:* It was discovered that unit tests were running with
> memtable_allocation_type: offheap_objects when we ship C* with heap_buffers.
> So we changed that in CASSANDRA-19326, now we test with
> memtable_allocation_type: heap_buffers. As a result, this test now fails all
> the time on 4.0 and 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-19602) Test Failure: Java upgrade tests failing
[
https://issues.apache.org/jira/browse/CASSANDRA-19602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19602:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: Java upgrade tests failing
>
>
> Key: CASSANDRA-19602
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19602
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> As seen below plenty of java upgrade tests are failing on trunk:
> {code:java}
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHarryTest.simpleUpgradeTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.CompactStorageHiddenColumnTest.testHiddenColumnWithCompactStorage-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedCoordinatorTest.testAvailability-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeleteRow-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeletePartition-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 3/8 /
> org.apache.cassandra.distributed.upgrade.UpgradeTest.simpleUpgradeWithNetworkAndGossipTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHintsTest.upgradeWithHintsTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.CompactStorageImplicitNullInClusteringTest.testImplicitNullInClusteringWithCompactStorage-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedReplicaTest.testAvailability-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairInsert-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 4/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairUpdate-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHostIdTest.upgradeHostIdUpdateTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingTest.testPagingWithCompactStorage-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV30Test.testConsistency-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 5/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeRepairTest.testRepairDuringMajorUpgrade-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostsTest.upgradeIgnoreHostsTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeFrom3LoggedBatchTest.testSimpleStrategy-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 6/8 /
> org.apache.cassandra.distributed.upgrade.MixedModeTTLOverflowAfterUpgradeTest.testTTLOverflowAfterUpgrade-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostTest.upgradeIgnoreHostsTest-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
> Tests / jvm-dtest-upgrade jdk11 7/8 /
> org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
>
[jira] [Created] (CASSANDRA-19602) Test Failure: Java upgrade tests failing
Ekaterina Dimitrova created CASSANDRA-19602:
---
Summary: Test Failure: Java upgrade tests failing
Key: CASSANDRA-19602
URL: https://issues.apache.org/jira/browse/CASSANDRA-19602
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
As seen below plenty of java upgrade tests are failing on trunk:
{code:java}
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHarryTest.simpleUpgradeTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.CompactStorageHiddenColumnTest.testHiddenColumnWithCompactStorage-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedCoordinatorTest.testAvailability-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeleteRow-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairDeleteTest.mixedModeReadRepairDeletePartition-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 3/8 /
org.apache.cassandra.distributed.upgrade.UpgradeTest.simpleUpgradeWithNetworkAndGossipTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHintsTest.upgradeWithHintsTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.CompactStorageImplicitNullInClusteringTest.testImplicitNullInClusteringWithCompactStorage-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityUpgradedReplicaTest.testAvailability-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairInsert-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 4/8 /
org.apache.cassandra.distributed.upgrade.MixedModeReadRepairWriteTest.mixedModeReadRepairUpdate-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeHostIdTest.upgradeHostIdUpdateTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingTest.testPagingWithCompactStorage-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.MixedModeConsistencyV30Test.testConsistency-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 5/8 /
org.apache.cassandra.distributed.upgrade.MixedModeRepairTest.testRepairDuringMajorUpgrade-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostsTest.upgradeIgnoreHostsTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV40Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.MixedModeFrom3LoggedBatchTest.testSimpleStrategy-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 6/8 /
org.apache.cassandra.distributed.upgrade.MixedModeTTLOverflowAfterUpgradeTest.testTTLOverflowAfterUpgrade-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeIgnoreHostTest.upgradeIgnoreHostsTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageMultipleClusterings-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageSingleClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.CompactStoragePagingWithProtocolV41Test.testPagingWithCompactStorageWithoutClustering-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.MixedModeFrom3ReplicationTest.testSimpleStrategy-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 7/8 /
org.apache.cassandra.distributed.upgrade.MixedModeTTLOverflowDuringUpgradeTest.testTTLOverflowDuringUpgrade-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 8/8 /
org.apache.cassandra.distributed.upgrade.ClusterMetadataUpgradeTest.simpleUpgradeTest-_jdk11_x86_64
Tests / jvm-dtest-upgrade jdk11 8/8 /
[jira] [Created] (CASSANDRA-19601) Test failure: test_change_durable_writes
Ekaterina Dimitrova created CASSANDRA-19601:
---
Summary: Test failure: test_change_durable_writes
Key: CASSANDRA-19601
URL: https://issues.apache.org/jira/browse/CASSANDRA-19601
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failing on trunk:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1880/testReport/junit/dtest-latest.configuration_test/TestConfiguration/Tests___dtest_latest_jdk11_31_64___test_change_durable_writes/]
[https://app.circleci.com/pipelines/github/blerer/cassandra/400/workflows/893a0edb-9181-4981-b542-77228c8bc975/jobs/10941/tests]
{code:java}
AssertionError: Commitlog was written with durable writes disabled
assert 90112 == 86016
+90112
-86016
self =
@pytest.mark.timeout(60*30)
def test_change_durable_writes(self):
"""
@jira_ticket CASSANDRA-9560
Test that changes to the DURABLE_WRITES option on keyspaces is
respected in subsequent writes.
This test starts by writing a dataset to a cluster and asserting that
the commitlogs have been written to. The subsequent test depends on
the assumption that this dataset triggers an fsync.
After checking this assumption, the test destroys the cluster and
creates a fresh one. Then it tests that DURABLE_WRITES is respected by:
- creating a keyspace with DURABLE_WRITES set to false,
- using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
- writing a dataset to this keyspace that is known to trigger a
commitlog fsync,
- asserting that the commitlog has grown in size since the data was
written.
"""
cluster = self.cluster
cluster.set_batch_commitlog(enabled=True, use_batch_window =
cluster.version() < '5.0')
cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
cluster.populate(1).start()
durable_node = cluster.nodelist()[0]
durable_init_size = commitlog_size(durable_node)
durable_session = self.patient_exclusive_cql_connection(durable_node)
# test assumption that write_to_trigger_fsync actually triggers a
commitlog fsync
durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
{'class': 'SimpleStrategy', 'replication_factor': 1} "
"AND DURABLE_WRITES = true")
durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
int, b int, c int)')
logger.debug('commitlog size diff = ' +
str(commitlog_size(durable_node) - durable_init_size))
write_to_trigger_fsync(durable_session, 'ks', 'tab')
logger.debug('commitlog size diff = ' +
str(commitlog_size(durable_node) - durable_init_size))
assert commitlog_size(durable_node) > durable_init_size, \
"This test will not work in this environment;
write_to_trigger_fsync does not trigger fsync."
durable_session.shutdown()
cluster.stop()
cluster.clear()
cluster.set_batch_commitlog(enabled=True, use_batch_window =
cluster.version() < '5.0')
cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
cluster.start()
node = cluster.nodelist()[0]
session = self.patient_exclusive_cql_connection(node)
# set up a keyspace without durable writes, then alter it to use them
session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
'SimpleStrategy', 'replication_factor': 1} "
"AND DURABLE_WRITES = false")
session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
int, c int)')
init_size = commitlog_size(node)
write_to_trigger_fsync(session, 'ks', 'tab')
> assert commitlog_size(node) == init_size, "Commitlog was written with
> durable writes disabled"
E AssertionError: Commitlog was written with durable writes disabled
E assert 90112 == 86016
E +90112
E -86016
configuration_test.py:104: AssertionError
{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-19601) Test failure: test_change_durable_writes
[
https://issues.apache.org/jira/browse/CASSANDRA-19601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19601:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure: test_change_durable_writes
>
>
> Key: CASSANDRA-19601
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19601
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1880/testReport/junit/dtest-latest.configuration_test/TestConfiguration/Tests___dtest_latest_jdk11_31_64___test_change_durable_writes/]
> [https://app.circleci.com/pipelines/github/blerer/cassandra/400/workflows/893a0edb-9181-4981-b542-77228c8bc975/jobs/10941/tests]
> {code:java}
> AssertionError: Commitlog was written with durable writes disabled
> assert 90112 == 86016
> +90112
> -86016
> self =
> @pytest.mark.timeout(60*30)
> def test_change_durable_writes(self):
> """
> @jira_ticket CASSANDRA-9560
>
> Test that changes to the DURABLE_WRITES option on keyspaces is
> respected in subsequent writes.
>
> This test starts by writing a dataset to a cluster and asserting that
> the commitlogs have been written to. The subsequent test depends on
> the assumption that this dataset triggers an fsync.
>
> After checking this assumption, the test destroys the cluster and
> creates a fresh one. Then it tests that DURABLE_WRITES is respected
> by:
>
> - creating a keyspace with DURABLE_WRITES set to false,
> - using ALTER KEYSPACE to set its DURABLE_WRITES option to true,
> - writing a dataset to this keyspace that is known to trigger a
> commitlog fsync,
> - asserting that the commitlog has grown in size since the data was
> written.
> """
> cluster = self.cluster
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
>
> cluster.populate(1).start()
> durable_node = cluster.nodelist()[0]
>
> durable_init_size = commitlog_size(durable_node)
> durable_session = self.patient_exclusive_cql_connection(durable_node)
>
> # test assumption that write_to_trigger_fsync actually triggers a
> commitlog fsync
> durable_session.execute("CREATE KEYSPACE ks WITH REPLICATION =
> {'class': 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = true")
> durable_session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a
> int, b int, c int)')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
> write_to_trigger_fsync(durable_session, 'ks', 'tab')
> logger.debug('commitlog size diff = ' +
> str(commitlog_size(durable_node) - durable_init_size))
>
> assert commitlog_size(durable_node) > durable_init_size, \
> "This test will not work in this environment;
> write_to_trigger_fsync does not trigger fsync."
>
> durable_session.shutdown()
> cluster.stop()
> cluster.clear()
>
> cluster.set_batch_commitlog(enabled=True, use_batch_window =
> cluster.version() < '5.0')
>
> cluster.set_configuration_options(values={'commitlog_segment_size_in_mb': 1})
> cluster.start()
> node = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node)
>
> # set up a keyspace without durable writes, then alter it to use them
> session.execute("CREATE KEYSPACE ks WITH REPLICATION = {'class':
> 'SimpleStrategy', 'replication_factor': 1} "
> "AND DURABLE_WRITES = false")
> session.execute('CREATE TABLE ks.tab (key int PRIMARY KEY, a int, b
> int, c int)')
> init_size = commitlog_size(node)
> write_to_trigger_fsync(session, 'ks', 'tab')
> > assert commitlog_size(node) == init_size, "Commitlog was written with
> > durable writes disabled"
> E AssertionError: Commitlog was written with durable writes disabled
> E assert 90112 == 86016
> E +90112
> E -86016
> configuration_test.py:104: AssertionError
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CASSANDRA-19341) Relation and Restriction hierachies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19341:
Fix Version/s: 5.x
> Relation and Restriction hierachies are too complex and error prone
> ---
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 21h 50m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19341) Relation and Restriction hierachies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19341:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Relation and Restriction hierachies are too complex and error prone
> ---
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Time Spent: 21h 50m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
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-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19583:
Summary: Make 0 work as 0+unit for all three config classes
(DataStorageSpec, DurationSpec, DataRateSpec) (was: enable Make 0 work as
0+unit for all three config classes (DataStorageSpec, DurationSpec,
DataRateSpec))
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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-19583) enable Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19583:
Description:
The inline docs say:
{noformat}
Setting this to 0 disables throttling.
{noformat}
However, on startup, we throw this error:
{noformat}
Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames omitted
{noformat}
We should allow 0 without a unit attached for data, duration, and data spec
config parameters, as 0 is always 0 no matter the unit.
was:
The inline docs say:
{noformat}
Setting this to 0 disables throttling.
{noformat}
However, on startup, we throw this error:
{noformat}
Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
Apr 23 23:12:01 cassandra0 cassandra[3424]: at
org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames omitted
{noformat}
We should allow 0 as per the inline doc.
> enable Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
> ---
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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-19583) setting compaction throughput to 0 throws a startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842048#comment-17842048
]
Ekaterina Dimitrova edited comment on CASSANDRA-19583 at 4/29/24 3:53 PM:
--
{quote}0 can mean "unlimited", but "0MiB/s" indicates actually zero.
{quote}
This confused me.
{quote}To be clear, I'm suggesting we make "0" work, without a unit. I'm not
suggesting we change how 0MiB/s works. They can be equivalent.
{quote}
Thanks for clarifying.
Then let's change this ticket to improvement and change its description to
"enable 0 to work as 0+unit for all three config classes (DataStorageSpec,
DurationSpec, DataRateSpec)" and not particularly for the compaction throughput
config?
was (Author: e.dimitrova):
{quote}0 can mean "unlimited", but "0MiB/s" indicates actually zero.
{quote}
This confused me.
{quote}
To be clear, I'm suggesting we make "0" work, without a unit. I'm not
suggesting we change how 0MiB/s works. They can be equivalent.
{quote}
Thanks for clarifying.
Then let's change this ticket to improvement and change its description to
"enable 0 to work as 0+unit for all three cofig classes (DataStorageSpec,
DurationSpec, DataRateSpec)" and not particularly for the compaction throughput
config?
> setting compaction throughput to 0 throws a startup error
> -
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 as per the inline doc.
--
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-19583) setting compaction throughput to 0 throws a startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842048#comment-17842048
]
Ekaterina Dimitrova commented on CASSANDRA-19583:
-
{quote}0 can mean "unlimited", but "0MiB/s" indicates actually zero.
{quote}
This confused me.
{quote}
To be clear, I'm suggesting we make "0" work, without a unit. I'm not
suggesting we change how 0MiB/s works. They can be equivalent.
{quote}
Thanks for clarifying.
Then let's change this ticket to improvement and change its description to
"enable 0 to work as 0+unit for all three cofig classes (DataStorageSpec,
DurationSpec, DataRateSpec)" and not particularly for the compaction throughput
config?
> setting compaction throughput to 0 throws a startup error
> -
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 as per the inline doc.
--
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-19583) setting compaction throughput to 0 throws a startup error
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842041#comment-17842041
]
Ekaterina Dimitrova commented on CASSANDRA-19583:
-
{quote} "0MiB/s" indicates actually zero.
{quote}
Indeed, this is something we saw with the old config pre-4.1 - there were cases
where 0 did not mean 0, or we used negatives or -1 to special case things,
which was very confusing IMHO.
Post-4.1 we encourage people to use guardrails or null for any special case
with the new config (as documented here -
[https://cassandra.apache.org/doc/4.1/cassandra/configuration/configuration.html,]
section {*}Notes for Cassandra Developers{*}). Unfortunately, we have to live
with the realities of some old configurations so we do not change
behavior/introduce regressions.
Compaction throughput is one of them - 0MiB/s always meant unlimited; the unit
was part of the config name, so we had to preserve the behavior. Also, it could
be unclear to special case 0 while having 0 with unit means something else.
Using null or guardrail sounds more deterministic. Last but not least, I think
it is too late to change the meaning of 0MiB/s for compaction throughput as it
was already released in 4.1 to mean "unlimited," and technically, it did not
change anything from before, where the unit was just in the name of the
parameter. We never had 0MiB/s meaning 0 for that property.
> setting compaction throughput to 0 throws a startup error
> -
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 as per the inline doc.
--
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-19566) JSON encoded timestamp value does not always match non-JSON encoded value
[
https://issues.apache.org/jira/browse/CASSANDRA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838985#comment-17838985
]
Ekaterina Dimitrova commented on CASSANDRA-19566:
-
Maybe I misunderstood something, isn’t Jenkins dev back to business after the
standalone Jenkins file was committed?
I see some runs here
[https://ci-cassandra.apache.org/job/Cassandra-5-devbranch/116/]
[~mck] ?
> JSON encoded timestamp value does not always match non-JSON encoded value
> -
>
> Key: CASSANDRA-19566
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19566
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Bowen Song
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description:
> "SELECT JSON ..." and "toJson(...)" on Cassandra 4.1.4 produces different
> date than "SELECT ..." for some timestamp type values.
>
> Steps to reproduce:
> {code:java}
> $ sudo docker pull cassandra:4.1.4
> $ sudo docker create --name cass cassandra:4.1.4
> $ sudo docker start cass
> $ # wait for the Cassandra instance becomes ready
> $ sudo docker exec -ti cass cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.1.0 | Cassandra 4.1.4 | CQL spec 3.4.6 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table tbl (id int, ts timestamp, primary key (id));
> cqlsh:test> insert into tbl (id, ts) values (1, -1376701920);
> cqlsh:test> select tounixtimestamp(ts), ts, tojson(ts) from tbl where id=1;
> system.tounixtimestamp(ts) | ts |
> system.tojson(ts)
> +-+
> -1376701920 | 1533-09-28 12:00:00.00+ | "1533-09-18
> 12:00:00.000Z"
> (1 rows)
> cqlsh:test> select json * from tbl where id=1;
> [json]
> -
> {"id": 1, "ts": "1533-09-18 12:00:00.000Z"}
> (1 rows)
> {code}
>
> Expected behaviour:
> The "select ts", "select tojson(ts)" and "select json *" should all produce
> the same date.
>
> Actual behaviour:
> The "select ts" produced the "1533-09-28" date but the "select tojson(ts)"
> and "select json *" produced the "1533-09-18" date.
--
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-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838303#comment-17838303
]
Ekaterina Dimitrova commented on CASSANDRA-19565:
-
{quote} perhaps should continue that here
{quote}
That is what I would expect too
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Fix For: 4.1.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
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-19565) SIGSEGV on Cassandra v4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-19565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838287#comment-17838287
]
Ekaterina Dimitrova commented on CASSANDRA-19565:
-
{quote}I think updating something as far reaching as JNA in a minor release is
a tough sell, especially if we are only gaining cosmetics which we can obviate
the need for by changing the ownership in the packaging.
{quote}
+1 on what [~brandon.williams] said. If we can limit the amount of change to
only change of ownership with no side effects, I think the risk updating by
exception JNA in a patch release is not justified. It would require also @dev
discussion
> SIGSEGV on Cassandra v4.1.4
> ---
>
> Key: CASSANDRA-19565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19565
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Fix For: 4.1.x
>
> Attachments: hs_err_pid1116450.log
>
>
> Hello,
> Since upgrading to v4.1. we cannat run CAssandra any more. Each start
> immediately crashes:
> {{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been
> detected by the Java Runtime Environment:
> Apr 17 08:58:34 SVALD108 cassandra[1116450]: # SIGSEGV (0xb) at
> pc=0x7fccaab4d152, pid=1116450, tid=1116451}}
> I have added the log from the coe dump.
> This issue is perhaps related to
> https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
--
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-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837338#comment-17837338
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
Hey [~jonmeredith], I haven't tried myself, but I have people telling me they
reproduced the issue on 4.0.
I can try to ask for more details if that will help you.
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
>
[jira] [Commented] (CASSANDRA-18736) Streaming exception race creates corrupt transaction log files that prevent restart
[
https://issues.apache.org/jira/browse/CASSANDRA-18736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837291#comment-17837291
]
Ekaterina Dimitrova commented on CASSANDRA-18736:
-
[~jonmeredith] , the fix versions mention 4.0, but I do not see a branch for
it. Do you plan to apply it on that branch too?
> Streaming exception race creates corrupt transaction log files that prevent
> restart
> ---
>
> Key: CASSANDRA-18736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18736
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
>
> On restart, Cassandra logs this message and terminates.
> {code:java}
> ERROR 2023-07-17T17:17:22,931 [main]
> org.apache.cassandra.db.lifecycle.LogTransaction:561 - Unexpected disk state:
> failed to read transaction log
> [nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log in
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043]
> Files and contents follow:
> /datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb_txn_stream_39d5f6b0-fb81-11ed-8f46-e97b3f61511e.log
> ABORT:[,0,0][737437348]
> ***This record should have been the last one in all replicas
>
> ADD:[/datadir1/keyspace/table-c9527530a0d611e8813f034699fc9043/nb-284490-big-,0,8][2493503833]
> {code}
> The root cause is a race during streaming exception handling.
> Although concurrent modification of to the {{LogTransaction}} was added for
> CASSANDRA-16225, there is nothing to prevent usage after the transaction is
> completed (committed/aborted) once it has been processed by
> {{TransactionTidier}} (after the last reference is released). Before the
> transaction is tidied, the {{LogFile}} keeps a list of records that are
> checked for completion before adding new entries. In {{TransactionTidier}}
> {{LogFile.records}} are cleared as no longer needed, however the
> LogTransaction/LogFile is still accessible to the stream.
> The changes in CASSANDRA-17273 added a parallel set of {{onDiskRecords}} that
> could be used to reliably recreate the transaction log at any new datadirs
> the same as the existing
> datadirs - regardless of the effect of
> {{LogTransaction.untrackNew/LogFile.remove}}
> If a streaming exception causes the LogTransaction to be aborted and tidied
> just before {{SimpleSSTableMultiWriter}} calls trackNew to add a new sstable.
> At the time of the call, the {{LogFile}} will not contain any {{LogReplicas}},
> {{LogFile.records}} will be empty, and {{LogFile.onDiskRecords}} will contain
> an {{ABORT}}.
> When {{LogTransaction.trackNew/LogFile.add}} is called, the check for
> completed transaction fails as records is empty, there are no replicas on the
> datadir, so {{maybeCreateReplicas}} creates a new txnlog file replica
> containing ABORT, then
> appends an ADD record.
> The LogFile has already been tidied after the abort so the txnlog file is not
> removed and sits on disk until a restart, causing the faiulre.
> There is a related exception caused with a different interleaving of aborts,
> after an sstable is added, however this is just a nuisance in the logs as the
> LogRelica is already created with an {{ADD}} record first.
> {code:java}
> java.lang.AssertionError:
> [ADD:[/datadir1/keyspace/table/nb-23314378-big-,0,8][1869379820]] is not
> tracked by 55be35b0-35d1-11ee-865d-8b1e3c48ca06
> at org.apache.cassandra.db.lifecycle.LogFile.remove(LogFile.java:388)
> at
> org.apache.cassandra.db.lifecycle.LogTransaction.untrackNew(LogTransaction.java:158)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.untrackNew(LifecycleTransaction.java:577)
> at
> org.apache.cassandra.db.streaming.CassandraStreamReceiver$1.untrackNew(CassandraStreamReceiver.java:149)
> at
> org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.abort(SimpleSSTableMultiWriter.java:95)
> at
> org.apache.cassandra.io.sstable.format.RangeAwareSSTableWriter.abort(RangeAwareSSTableWriter.java:191)
> at
> org.apache.cassandra.db.streaming.CassandraCompressedStreamReader.read(CassandraCompressedStreamReader.java:115)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:85)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:53)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:38)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:53)
>
[jira] [Commented] (CASSANDRA-18831) Enable Cassandra to build and run under JDK21
[
https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836282#comment-17836282
]
Ekaterina Dimitrova commented on CASSANDRA-18831:
-
{quote}We bumped many of the dependencies already with 5.0
{quote}
{quote}Yep. Some of these I'm having to bump again were updated late last year
or .ea versions released in the past few months for JDK21 support since so much
more keeps getting locked down. Happening in spaces heavy with reflection (i.e.
testing, debugging, logging), not in production data serving paths, so I'm not
too worried about the introduction of the deps in their current forms.
{quote}
I agree with everything said. My point was more about the fact that you don't
have to update dependencies that haven't been touched in 5-6 years (there are
plenty of versions in between with breaking changes and long change logs to
consider). I hope that it makes it at least a bit easier and faster. Thanks
again for moving forward with this one!
> Enable Cassandra to build and run under JDK21
> -
>
> Key: CASSANDRA-18831
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18831
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Achilles Benetopoulos
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 5.x
>
> Attachments: jdk21-patch
>
>
> This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list
> of supported Java versions, and extends that work to enable building and
> running Cassandra under JDK21.
> The following commits comprise the changes included in the attached patch:
> -
> [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47]
> -
> [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897]
> -
> [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913]
> -
> [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451]
--
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-18831) Enable Cassandra to build and run under JDK21
[ https://issues.apache.org/jira/browse/CASSANDRA-18831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836266#comment-17836266 ] Ekaterina Dimitrova commented on CASSANDRA-18831: - Thanks [~jmckenzie], I am happy to see this progressing! bq. I'll pursue getting that set up formally in the ASF space after we have general support merged That is what we were doing before, too - whatever can be merged and it is not breaking with the previous versions, gets merged. Some of the updates that were needed for JDK17 were committed from 4.1. Whatever will require a previous JDK version to be dropped (we maintain two) - it waits until the drop. The only issue is that there will be breakages until we have it in CI, as people do not test their patches on the new version, but we can't have everything. I was also fixing every now and then the broken trunk. We bumped many of the dependencies already with 5.0 > Enable Cassandra to build and run under JDK21 > - > > Key: CASSANDRA-18831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18831 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Achilles Benetopoulos >Assignee: Josh McKenzie >Priority: Normal > Fix For: 5.x > > Attachments: jdk21-patch > > > This patch builds on the work in CASSANDRA-16895 that added JDK17 to the list > of supported Java versions, and extends that work to enable building and > running Cassandra under JDK21. > The following commits comprise the changes included in the attached patch: > - > [https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47] > - > [https://github.com/apache/cassandra/commit/0c5df38dafe58bfec8924e81507bb604e1543897] > - > [https://github.com/apache/cassandra/commit/6506b7279d98eed4b2b65b71e0c6f41eb78c6913] > - > [https://github.com/apache/cassandra/commit/564cbd534c5a975cda0c629c14c68c8745b41451] -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835001#comment-17835001 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 4/8/24 4:54 PM: - Opened tickets for the rest of the test failures and linked them here and in Butler. was (Author: e.dimitrova): Opened tickets for the rest of the test failures and linked them and in Butler. > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835001#comment-17835001 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - Opened tickets for the rest of the test failures and linked them and in Butler. > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19540) Test Failure: test_sstablelevelreset
[
https://issues.apache.org/jira/browse/CASSANDRA-19540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19540:
Fix Version/s: 5.x
> Test Failure: test_sstablelevelreset
>
>
> Key: CASSANDRA-19540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19540
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> self =
> def test_sstablelevelreset(self):
> """
> Insert data and call sstablelevelreset on a series of
> tables. Confirm level is reset to 0 using its output.
> Test a variety of possible errors and ensure response is resonable.
> @since 2.1.5
> @jira_ticket CASSANDRA-7614
> """
> cluster = self.cluster
> cluster.populate(1).start()
> node1 = cluster.nodelist()[0]
>
> # test by trying to run on nonexistent keyspace
> cluster.stop(gently=False)
> try:
> node1.run_sstablelevelreset("keyspace1", "standard1")
> except ToolError as e:
> assert re.search("ColumnFamily not found: keyspace1/standard1",
> str(e))
> # this should return exit code 1
> assert e.exit_status == 1, "Expected sstablelevelreset to have a
> return code of 1 == but instead return code was {}".format(
> e.exit_status)
>
> # now test by generating keyspace but not flushing sstables
> cluster.start()
> node1.stress(['write', 'n=100', 'no-warmup', '-schema',
> 'replication(factor=1)',
> '-rate', 'threads=8'])
> cluster.stop(gently=False)
>
> output, error, rc = node1.run_sstablelevelreset("keyspace1",
> "standard1")
> self._check_stderr_error(error)
> assert re.search("Found no sstables, did you give the correct
> keyspace", output)
> assert rc == 0, str(rc)
>
> # test by writing small amount of data and flushing (all sstables
> should be level 0)
> cluster.start()
> session = self.patient_cql_connection(node1)
> > session.execute(
> "ALTER TABLE keyspace1.standard1 with compaction={'class':
> 'LeveledCompactionStrategy', 'sstable_size_in_mb':1};")
> offline_tools_test.py:64:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042 coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> test_sstableofflinerelevel
> FLAKY
> offline_tools_test.TestOfflineTools
> test_resumable_decommission
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> The failure looks different in Jenkins:
>
[jira] [Updated] (CASSANDRA-19543) Test Failure: testConcurrentReadWriteWorkload
[
https://issues.apache.org/jira/browse/CASSANDRA-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19543:
Fix Version/s: 5.x
> Test Failure: testConcurrentReadWriteWorkload
> -
>
> Key: CASSANDRA-19543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19543
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Flaky on trunk, seen in Butler and here:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58940/tests#failed-test-0
> {code:java}
> java.lang.RuntimeException: Interrupting run because of an exception
> at
> org.apache.cassandra.harry.runner.Runner.mergeAndThrow(Runner.java:395)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.runInternal(Runner.java:305)
> at org.apache.cassandra.harry.runner.Runner.run(Runner.java:77)
> at
> org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload(ConcurrentQuiescentCheckerIntegrationTest.java:62)
> 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)
> Caused by: org.apache.cassandra.exceptions.ReadFailureException: Operation
> failed - received 0 responses and 1 failures: UNKNOWN from /127.0.0.1:7012
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:161)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:396)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2071)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1941)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1818)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:479)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:75)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:483)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:540)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:347)
> at
> org.apache.cassandra.distributed.impl.Coordinator$1.hasNext(Coordinator.java:220)
> at
> org.apache.cassandra.distributed.api.QueryResults$1.hasNext(QueryResults.java:55)
> at
> org.apache.cassandra.distributed.api.QueryResults$IteratorQueryResult.hasNext(QueryResults.java:166)
> at
> org.apache.cassandra.distributed.api.QueryResult$1.hasNext(QueryResult.java:76)
> at com.google.common.collect.Iterators.addAll(Iterators.java:365)
> at com.google.common.collect.Lists.newArrayList(Lists.java:146)
> at com.google.common.collect.Iterators.toArray(Iterators.java:349)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:156)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:139)
> at
> org.apache.cassandra.harry.sut.SystemUnderTest.executeIdempotent(SystemUnderTest.java:54)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:328)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:322)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.lambda$validate$0(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:78)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.visitors.RandomPartitionValidator.visit(RandomPartitionValidator.java:56)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.lambda$runInternal$0(Runner.java:296)
> at
> org.apache.cassandra.harry.runner.Runner.lambda$wrapInterrupt$3(Runner.java:368)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
>
[jira] [Updated] (CASSANDRA-19543) Test Failure: testConcurrentReadWriteWorkload
[
https://issues.apache.org/jira/browse/CASSANDRA-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19543:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Test/dtest/java
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: testConcurrentReadWriteWorkload
> -
>
> Key: CASSANDRA-19543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19543
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Flaky on trunk, seen in Butler and here:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58940/tests#failed-test-0
> {code:java}
> java.lang.RuntimeException: Interrupting run because of an exception
> at
> org.apache.cassandra.harry.runner.Runner.mergeAndThrow(Runner.java:395)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.runInternal(Runner.java:305)
> at org.apache.cassandra.harry.runner.Runner.run(Runner.java:77)
> at
> org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload(ConcurrentQuiescentCheckerIntegrationTest.java:62)
> 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)
> Caused by: org.apache.cassandra.exceptions.ReadFailureException: Operation
> failed - received 0 responses and 1 failures: UNKNOWN from /127.0.0.1:7012
> at
> org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:161)
> at
> org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:396)
> at
> org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2071)
> at
> org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1941)
> at
> org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1818)
> at
> org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:479)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:75)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:483)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:540)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:347)
> at
> org.apache.cassandra.distributed.impl.Coordinator$1.hasNext(Coordinator.java:220)
> at
> org.apache.cassandra.distributed.api.QueryResults$1.hasNext(QueryResults.java:55)
> at
> org.apache.cassandra.distributed.api.QueryResults$IteratorQueryResult.hasNext(QueryResults.java:166)
> at
> org.apache.cassandra.distributed.api.QueryResult$1.hasNext(QueryResult.java:76)
> at com.google.common.collect.Iterators.addAll(Iterators.java:365)
> at com.google.common.collect.Lists.newArrayList(Lists.java:146)
> at com.google.common.collect.Iterators.toArray(Iterators.java:349)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:156)
> at
> org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:139)
> at
> org.apache.cassandra.harry.sut.SystemUnderTest.executeIdempotent(SystemUnderTest.java:54)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:328)
> at
> org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:322)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.lambda$validate$0(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:78)
> at
> org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:72)
> at
> org.apache.cassandra.harry.visitors.RandomPartitionValidator.visit(RandomPartitionValidator.java:56)
> at
> org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.lambda$runInternal$0(Runner.java:296)
> at
> org.apache.cassandra.harry.runner.Runner.lambda$wrapInterrupt$3(Runner.java:368)
> at
>
[jira] [Updated] (CASSANDRA-19542) Test Failure: test_resumable_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19542:
Fix Version/s: 5.x
> Test Failure: test_resumable_decommission
> -
>
> Key: CASSANDRA-19542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19542
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> self =
> @since('3.10')
> def test_resumable_decommission(self):
> """
> @jira_ticket CASSANDRA-12008
>
> Test decommission operation is resumable
> """
> self.fixture_dtest_setup.ignore_log_patterns = [r'Streaming error
> occurred',
> r'Error while
> decommissioning node',
> r'Remote peer
> 127.0.0.2 failed stream session',
> r'Remote peer
> \/?127.0.0.2:7000 failed stream session',
> r'peer 127.0.0.2:7000
> is probably down',]
> cluster = self.cluster
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(3, install_byteman=True).start()
> node1, node2, node3 = cluster.nodelist()
>
> session = self.patient_cql_connection(node2)
> # reduce system_distributed RF to 2 so we don't require forceful
> decommission
> session.execute("ALTER KEYSPACE system_distributed WITH REPLICATION =
> {'class':'SimpleStrategy', 'replication_factor':'2'};")
> create_ks(session, 'ks', 2)
> create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
> insert_c1c2(session, n=1, consistency=ConsistencyLevel.ALL)
>
> # Execute first rebuild, should fail
> with pytest.raises(ToolError):
> if cluster.version() >= '4.0':
> script = [mk_bman_path('4.0/decommission_failure_inject.btm')]
> else:
> script =
> [mk_bman_path('pre4.0/decommission_failure_inject.btm')]
> node2.byteman_submit(script)
> node2.nodetool('decommission')
>
> # Make sure previous ToolError is due to decommission
> node2.watch_log_for('Error while decommissioning node')
>
> # Decommission again
> mark = node2.mark_log()
> node2.nodetool('decommission')
>
> # Check decommision is done and we skipped transfereed ranges
> node2.watch_log_for('DECOMMISSIONED', from_mark=mark)
> node2.grep_log("Skipping transferred range .* of keyspace ks,
> endpoint {}".format(node2.address_for_current_version_slashy()),
> filename='debug.log')
>
> # Check data is correctly forwarded to node1 and node3
> cluster.remove(node2)
> node3.stop(gently=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> for i in range(0, 1):
> query_c1c2(session, i, ConsistencyLevel.ONE)
> node1.stop(gently=False)
> node3.start()
> session.shutdown()
> mark = node3.mark_log()
> node3.watch_log_for('Starting listening for CQL clients',
> from_mark=mark)
> session = self.patient_exclusive_cql_connection(node3)
> session.execute('USE ks')
> for i in range(0, 1):
> > query_c1c2(session, i, ConsistencyLevel.ONE)
> topology_test.py:275:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:43: in query_c1c2
> assertions.assert_length_equal(rows, 1)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> object_with_length = [], expected_length = 1
> def assert_length_equal(object_with_length, expected_length):
> """
> Assert an object has a specific length.
> @param object_with_length The object whose length will be checked
> @param expected_length The expected length of the object
>
> Examples:
> assert_length_equal(res, nb_counter)
> """
> > assert len(object_with_length) == expected_length, \
> "Expected {} to have length {}, but instead is of length {}"\
> .format(object_with_length, expected_length,
> len(object_with_length))
> E AssertionError: Expected [] to have length 1, but instead is of
> length 0
> tools/assertions.py:267: AssertionError
> {code}
>
[jira] [Updated] (CASSANDRA-19542) Test Failure: test_resumable_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19542:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Test/dtest/python
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_resumable_decommission
> -
>
> Key: CASSANDRA-19542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19542
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> {code:java}
> self =
> @since('3.10')
> def test_resumable_decommission(self):
> """
> @jira_ticket CASSANDRA-12008
>
> Test decommission operation is resumable
> """
> self.fixture_dtest_setup.ignore_log_patterns = [r'Streaming error
> occurred',
> r'Error while
> decommissioning node',
> r'Remote peer
> 127.0.0.2 failed stream session',
> r'Remote peer
> \/?127.0.0.2:7000 failed stream session',
> r'peer 127.0.0.2:7000
> is probably down',]
> cluster = self.cluster
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(3, install_byteman=True).start()
> node1, node2, node3 = cluster.nodelist()
>
> session = self.patient_cql_connection(node2)
> # reduce system_distributed RF to 2 so we don't require forceful
> decommission
> session.execute("ALTER KEYSPACE system_distributed WITH REPLICATION =
> {'class':'SimpleStrategy', 'replication_factor':'2'};")
> create_ks(session, 'ks', 2)
> create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
> insert_c1c2(session, n=1, consistency=ConsistencyLevel.ALL)
>
> # Execute first rebuild, should fail
> with pytest.raises(ToolError):
> if cluster.version() >= '4.0':
> script = [mk_bman_path('4.0/decommission_failure_inject.btm')]
> else:
> script =
> [mk_bman_path('pre4.0/decommission_failure_inject.btm')]
> node2.byteman_submit(script)
> node2.nodetool('decommission')
>
> # Make sure previous ToolError is due to decommission
> node2.watch_log_for('Error while decommissioning node')
>
> # Decommission again
> mark = node2.mark_log()
> node2.nodetool('decommission')
>
> # Check decommision is done and we skipped transfereed ranges
> node2.watch_log_for('DECOMMISSIONED', from_mark=mark)
> node2.grep_log("Skipping transferred range .* of keyspace ks,
> endpoint {}".format(node2.address_for_current_version_slashy()),
> filename='debug.log')
>
> # Check data is correctly forwarded to node1 and node3
> cluster.remove(node2)
> node3.stop(gently=False)
> session = self.patient_exclusive_cql_connection(node1)
> session.execute('USE ks')
> for i in range(0, 1):
> query_c1c2(session, i, ConsistencyLevel.ONE)
> node1.stop(gently=False)
> node3.start()
> session.shutdown()
> mark = node3.mark_log()
> node3.watch_log_for('Starting listening for CQL clients',
> from_mark=mark)
> session = self.patient_exclusive_cql_connection(node3)
> session.execute('USE ks')
> for i in range(0, 1):
> > query_c1c2(session, i, ConsistencyLevel.ONE)
> topology_test.py:275:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> tools/data.py:43: in query_c1c2
> assertions.assert_length_equal(rows, 1)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> object_with_length = [], expected_length = 1
> def assert_length_equal(object_with_length, expected_length):
> """
> Assert an object has a specific length.
> @param object_with_length The object whose length will be checked
> @param expected_length The expected length of the object
>
> Examples:
> assert_length_equal(res, nb_counter)
> """
> > assert len(object_with_length) == expected_length, \
> "Expected {} to have length {}, but instead is of length {}"\
> .format(object_with_length, expected_length,
> len(object_with_length))
> E
[jira] [Created] (CASSANDRA-19543) Test Failure: testConcurrentReadWriteWorkload
Ekaterina Dimitrova created CASSANDRA-19543:
---
Summary: Test Failure: testConcurrentReadWriteWorkload
Key: CASSANDRA-19543
URL: https://issues.apache.org/jira/browse/CASSANDRA-19543
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Flaky on trunk, seen in Butler and here:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58940/tests#failed-test-0
{code:java}
java.lang.RuntimeException: Interrupting run because of an exception
at
org.apache.cassandra.harry.runner.Runner.mergeAndThrow(Runner.java:395)
at
org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.runInternal(Runner.java:305)
at org.apache.cassandra.harry.runner.Runner.run(Runner.java:77)
at
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest.testConcurrentReadWriteWorkload(ConcurrentQuiescentCheckerIntegrationTest.java:62)
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)
Caused by: org.apache.cassandra.exceptions.ReadFailureException: Operation
failed - received 0 responses and 1 failures: UNKNOWN from /127.0.0.1:7012
at
org.apache.cassandra.service.reads.ReadCallback.awaitResults(ReadCallback.java:161)
at
org.apache.cassandra.service.reads.AbstractReadExecutor.awaitResponses(AbstractReadExecutor.java:396)
at
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:2071)
at
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1941)
at
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1818)
at
org.apache.cassandra.db.SinglePartitionReadCommand.execute(SinglePartitionReadCommand.java:479)
at
org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:75)
at
org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
at
org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:483)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:540)
at
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:347)
at
org.apache.cassandra.distributed.impl.Coordinator$1.hasNext(Coordinator.java:220)
at
org.apache.cassandra.distributed.api.QueryResults$1.hasNext(QueryResults.java:55)
at
org.apache.cassandra.distributed.api.QueryResults$IteratorQueryResult.hasNext(QueryResults.java:166)
at
org.apache.cassandra.distributed.api.QueryResult$1.hasNext(QueryResult.java:76)
at com.google.common.collect.Iterators.addAll(Iterators.java:365)
at com.google.common.collect.Lists.newArrayList(Lists.java:146)
at com.google.common.collect.Iterators.toArray(Iterators.java:349)
at
org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:156)
at
org.apache.cassandra.harry.sut.injvm.InJvmSutBase.execute(InJvmSutBase.java:139)
at
org.apache.cassandra.harry.sut.SystemUnderTest.executeIdempotent(SystemUnderTest.java:54)
at
org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:328)
at
org.apache.cassandra.harry.model.SelectHelper.execute(SelectHelper.java:322)
at
org.apache.cassandra.harry.model.QuiescentChecker.lambda$validate$0(QuiescentChecker.java:72)
at
org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:78)
at
org.apache.cassandra.harry.model.QuiescentChecker.validate(QuiescentChecker.java:72)
at
org.apache.cassandra.harry.visitors.RandomPartitionValidator.visit(RandomPartitionValidator.java:56)
at
org.apache.cassandra.harry.runner.Runner$ConcurrentRunner.lambda$runInternal$0(Runner.java:296)
at
org.apache.cassandra.harry.runner.Runner.lambda$wrapInterrupt$3(Runner.java:368)
at
org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
{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-19542) Test Failure: test_resumable_decommission
Ekaterina Dimitrova created CASSANDRA-19542:
---
Summary: Test Failure: test_resumable_decommission
Key: CASSANDRA-19542
URL: https://issues.apache.org/jira/browse/CASSANDRA-19542
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
{code:java}
self =
@since('3.10')
def test_resumable_decommission(self):
"""
@jira_ticket CASSANDRA-12008
Test decommission operation is resumable
"""
self.fixture_dtest_setup.ignore_log_patterns = [r'Streaming error
occurred',
r'Error while
decommissioning node',
r'Remote peer 127.0.0.2
failed stream session',
r'Remote peer
\/?127.0.0.2:7000 failed stream session',
r'peer 127.0.0.2:7000
is probably down',]
cluster = self.cluster
cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
1})
cluster.populate(3, install_byteman=True).start()
node1, node2, node3 = cluster.nodelist()
session = self.patient_cql_connection(node2)
# reduce system_distributed RF to 2 so we don't require forceful
decommission
session.execute("ALTER KEYSPACE system_distributed WITH REPLICATION =
{'class':'SimpleStrategy', 'replication_factor':'2'};")
create_ks(session, 'ks', 2)
create_cf(session, 'cf', columns={'c1': 'text', 'c2': 'text'})
insert_c1c2(session, n=1, consistency=ConsistencyLevel.ALL)
# Execute first rebuild, should fail
with pytest.raises(ToolError):
if cluster.version() >= '4.0':
script = [mk_bman_path('4.0/decommission_failure_inject.btm')]
else:
script =
[mk_bman_path('pre4.0/decommission_failure_inject.btm')]
node2.byteman_submit(script)
node2.nodetool('decommission')
# Make sure previous ToolError is due to decommission
node2.watch_log_for('Error while decommissioning node')
# Decommission again
mark = node2.mark_log()
node2.nodetool('decommission')
# Check decommision is done and we skipped transfereed ranges
node2.watch_log_for('DECOMMISSIONED', from_mark=mark)
node2.grep_log("Skipping transferred range .* of keyspace ks, endpoint
{}".format(node2.address_for_current_version_slashy()), filename='debug.log')
# Check data is correctly forwarded to node1 and node3
cluster.remove(node2)
node3.stop(gently=False)
session = self.patient_exclusive_cql_connection(node1)
session.execute('USE ks')
for i in range(0, 1):
query_c1c2(session, i, ConsistencyLevel.ONE)
node1.stop(gently=False)
node3.start()
session.shutdown()
mark = node3.mark_log()
node3.watch_log_for('Starting listening for CQL clients',
from_mark=mark)
session = self.patient_exclusive_cql_connection(node3)
session.execute('USE ks')
for i in range(0, 1):
> query_c1c2(session, i, ConsistencyLevel.ONE)
topology_test.py:275:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tools/data.py:43: in query_c1c2
assertions.assert_length_equal(rows, 1)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
object_with_length = [], expected_length = 1
def assert_length_equal(object_with_length, expected_length):
"""
Assert an object has a specific length.
@param object_with_length The object whose length will be checked
@param expected_length The expected length of the object
Examples:
assert_length_equal(res, nb_counter)
"""
> assert len(object_with_length) == expected_length, \
"Expected {} to have length {}, but instead is of length {}"\
.format(object_with_length, expected_length,
len(object_with_length))
E AssertionError: Expected [] to have length 1, but instead is of length 0
tools/assertions.py:267: AssertionError
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
--
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-19541) Test Failure: test_sstableofflinerelevel
[
https://issues.apache.org/jira/browse/CASSANDRA-19541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19541:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: CI
Test/dtest/python
Discovered By: User Report
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_sstableofflinerelevel
> -
>
> Key: CASSANDRA-19541
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19541
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> {code:java}
> self =
> def test_sstableofflinerelevel(self):
> """
> Generate sstables of varying levels.
> Reset sstables to L0 with sstablelevelreset
> Run sstableofflinerelevel and ensure tables are promoted correctly
> Also test a variety of bad inputs including nonexistent keyspace and
> sstables
> @since 2.1.5
> @jira_ticket CASSANDRA-8031
> """
> cluster = self.cluster
>
> cluster.set_configuration_options(values={'compaction_throughput_mb_per_sec':
> 0})
> cluster.populate(1).start()
> node1 = cluster.nodelist()[0]
>
> # NOTE - As of now this does not return when it encounters Exception
> and causes test to hang, temporarily commented out
> # test by trying to run on nonexistent keyspace
> # cluster.stop(gently=False)
> # output, error, rc = node1.run_sstableofflinerelevel("keyspace1",
> "standard1", output=True)
> # assert "java.lang.IllegalArgumentException: Unknown
> keyspace/columnFamily keyspace1.standard1" in error
> # # this should return exit code 1
> # assert rc, 1 == msg=str(rc)
> # cluster.start()
>
> # now test by generating keyspace but not flushing sstables
>
> node1.stress(['write', 'n=1', 'no-warmup',
> '-schema', 'replication(factor=1)',
> '-col', 'n=FIXED(10)', 'SIZE=FIXED(1024)',
> '-rate', 'threads=8'])
>
> cluster.stop(gently=False)
> try:
> output, error, _ = node1.run_sstableofflinerelevel("keyspace1",
> "standard1")
> except ToolError as e:
> assert re.search("No sstables to relevel for
> keyspace1.standard1", e.stdout)
> assert e.exit_status == 1, str(e.exit_status)
>
> # test by flushing (sstable should be level 0)
> cluster.start()
> session = self.patient_cql_connection(node1)
> logger.debug("Altering compaction strategy to LCS")
> > session.execute(
> "ALTER TABLE keyspace1.standard1 with compaction={'class':
> 'LeveledCompactionStrategy', 'sstable_size_in_mb':1, 'enabled':'false'};")
> offline_tools_test.py:147:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042 coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
[jira] [Created] (CASSANDRA-19541) Test Failure: test_sstableofflinerelevel
Ekaterina Dimitrova created CASSANDRA-19541:
---
Summary: Test Failure: test_sstableofflinerelevel
Key: CASSANDRA-19541
URL: https://issues.apache.org/jira/browse/CASSANDRA-19541
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
{code:java}
self =
def test_sstableofflinerelevel(self):
"""
Generate sstables of varying levels.
Reset sstables to L0 with sstablelevelreset
Run sstableofflinerelevel and ensure tables are promoted correctly
Also test a variety of bad inputs including nonexistent keyspace and
sstables
@since 2.1.5
@jira_ticket CASSANDRA-8031
"""
cluster = self.cluster
cluster.set_configuration_options(values={'compaction_throughput_mb_per_sec':
0})
cluster.populate(1).start()
node1 = cluster.nodelist()[0]
# NOTE - As of now this does not return when it encounters Exception
and causes test to hang, temporarily commented out
# test by trying to run on nonexistent keyspace
# cluster.stop(gently=False)
# output, error, rc = node1.run_sstableofflinerelevel("keyspace1",
"standard1", output=True)
# assert "java.lang.IllegalArgumentException: Unknown
keyspace/columnFamily keyspace1.standard1" in error
# # this should return exit code 1
# assert rc, 1 == msg=str(rc)
# cluster.start()
# now test by generating keyspace but not flushing sstables
node1.stress(['write', 'n=1', 'no-warmup',
'-schema', 'replication(factor=1)',
'-col', 'n=FIXED(10)', 'SIZE=FIXED(1024)',
'-rate', 'threads=8'])
cluster.stop(gently=False)
try:
output, error, _ = node1.run_sstableofflinerelevel("keyspace1",
"standard1")
except ToolError as e:
assert re.search("No sstables to relevel for keyspace1.standard1",
e.stdout)
assert e.exit_status == 1, str(e.exit_status)
# test by flushing (sstable should be level 0)
cluster.start()
session = self.patient_cql_connection(node1)
logger.debug("Altering compaction strategy to LCS")
> session.execute(
"ALTER TABLE keyspace1.standard1 with compaction={'class':
'LeveledCompactionStrategy', 'sstable_size_in_mb':1, 'enabled':'false'};")
offline_tools_test.py:147:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def result(self):
"""
Return the final result or raise an Exception if errors were
encountered. If the final result or error has not been set
yet, this method will block until it is set, or the timeout
set for the request expires.
Timeout is specified in the Session request execution functions.
If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut` will
be raised.
This is a client-side timeout. For more information
about server-side coordinator timeouts, see
:class:`.policies.RetryPolicy`.
Example usage::
>>> future = session.execute_async("SELECT * FROM mycf")
>>> # do other stuff...
>>> try:
... rows = future.result()
... for row in rows:
... ... # process results
... except Exception:
... log.exception("Operation failed:")
"""
self._event.wait()
if self._final_result is not _NOT_SET:
return ResultSet(self, self._final_result)
else:
> raise self._final_exception
E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
request timeout. See Session.execute[_async](timeout)'},
last_host=127.0.0.1:9042
../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19540) Test Failure: test_sstablelevelreset
[
https://issues.apache.org/jira/browse/CASSANDRA-19540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19540:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_sstablelevelreset
>
>
> Key: CASSANDRA-19540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19540
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> {code:java}
> self =
> def test_sstablelevelreset(self):
> """
> Insert data and call sstablelevelreset on a series of
> tables. Confirm level is reset to 0 using its output.
> Test a variety of possible errors and ensure response is resonable.
> @since 2.1.5
> @jira_ticket CASSANDRA-7614
> """
> cluster = self.cluster
> cluster.populate(1).start()
> node1 = cluster.nodelist()[0]
>
> # test by trying to run on nonexistent keyspace
> cluster.stop(gently=False)
> try:
> node1.run_sstablelevelreset("keyspace1", "standard1")
> except ToolError as e:
> assert re.search("ColumnFamily not found: keyspace1/standard1",
> str(e))
> # this should return exit code 1
> assert e.exit_status == 1, "Expected sstablelevelreset to have a
> return code of 1 == but instead return code was {}".format(
> e.exit_status)
>
> # now test by generating keyspace but not flushing sstables
> cluster.start()
> node1.stress(['write', 'n=100', 'no-warmup', '-schema',
> 'replication(factor=1)',
> '-rate', 'threads=8'])
> cluster.stop(gently=False)
>
> output, error, rc = node1.run_sstablelevelreset("keyspace1",
> "standard1")
> self._check_stderr_error(error)
> assert re.search("Found no sstables, did you give the correct
> keyspace", output)
> assert rc == 0, str(rc)
>
> # test by writing small amount of data and flushing (all sstables
> should be level 0)
> cluster.start()
> session = self.patient_cql_connection(node1)
> > session.execute(
> "ALTER TABLE keyspace1.standard1 with compaction={'class':
> 'LeveledCompactionStrategy', 'sstable_size_in_mb':1};")
> offline_tools_test.py:64:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
> return self.execute_async(query, parameters, trace, custom_payload,
> timeout, execution_profile, paging_state, host, execute_as).result()
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042 coordinator_host=None>
> def result(self):
> """
> Return the final result or raise an Exception if errors were
> encountered. If the final result or error has not been set
> yet, this method will block until it is set, or the timeout
> set for the request expires.
>
> Timeout is specified in the Session request execution functions.
> If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised.
> This is a client-side timeout. For more information
> about server-side coordinator timeouts, see
> :class:`.policies.RetryPolicy`.
>
> Example usage::
>
> >>> future = session.execute_async("SELECT * FROM mycf")
> >>> # do other stuff...
>
> >>> try:
> ... rows = future.result()
> ... for row in rows:
> ... ... # process results
> ... except Exception:
> ... log.exception("Operation failed:")
>
> """
> self._event.wait()
> if self._final_result is not _NOT_SET:
> return ResultSet(self, self._final_result)
> else:
> > raise self._final_exception
> E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
> request timeout. See Session.execute[_async](timeout)'},
> last_host=127.0.0.1:9042
> ../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
> test_sstableofflinerelevel
> FLAKY
> offline_tools_test.TestOfflineTools
> test_resumable_decommission
> {code}
>
[jira] [Created] (CASSANDRA-19540) Test Failure: test_sstablelevelreset
Ekaterina Dimitrova created CASSANDRA-19540:
---
Summary: Test Failure: test_sstablelevelreset
Key: CASSANDRA-19540
URL: https://issues.apache.org/jira/browse/CASSANDRA-19540
Project: Cassandra
Issue Type: Bug
Components: Test/dtest/python
Reporter: Ekaterina Dimitrova
{code:java}
self =
def test_sstablelevelreset(self):
"""
Insert data and call sstablelevelreset on a series of
tables. Confirm level is reset to 0 using its output.
Test a variety of possible errors and ensure response is resonable.
@since 2.1.5
@jira_ticket CASSANDRA-7614
"""
cluster = self.cluster
cluster.populate(1).start()
node1 = cluster.nodelist()[0]
# test by trying to run on nonexistent keyspace
cluster.stop(gently=False)
try:
node1.run_sstablelevelreset("keyspace1", "standard1")
except ToolError as e:
assert re.search("ColumnFamily not found: keyspace1/standard1",
str(e))
# this should return exit code 1
assert e.exit_status == 1, "Expected sstablelevelreset to have a
return code of 1 == but instead return code was {}".format(
e.exit_status)
# now test by generating keyspace but not flushing sstables
cluster.start()
node1.stress(['write', 'n=100', 'no-warmup', '-schema',
'replication(factor=1)',
'-rate', 'threads=8'])
cluster.stop(gently=False)
output, error, rc = node1.run_sstablelevelreset("keyspace1",
"standard1")
self._check_stderr_error(error)
assert re.search("Found no sstables, did you give the correct
keyspace", output)
assert rc == 0, str(rc)
# test by writing small amount of data and flushing (all sstables
should be level 0)
cluster.start()
session = self.patient_cql_connection(node1)
> session.execute(
"ALTER TABLE keyspace1.standard1 with compaction={'class':
'LeveledCompactionStrategy', 'sstable_size_in_mb':1};")
offline_tools_test.py:64:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/src/cassandra-driver/cassandra/cluster.py:2618: in execute
return self.execute_async(query, parameters, trace, custom_payload,
timeout, execution_profile, paging_state, host, execute_as).result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
def result(self):
"""
Return the final result or raise an Exception if errors were
encountered. If the final result or error has not been set
yet, this method will block until it is set, or the timeout
set for the request expires.
Timeout is specified in the Session request execution functions.
If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut` will
be raised.
This is a client-side timeout. For more information
about server-side coordinator timeouts, see
:class:`.policies.RetryPolicy`.
Example usage::
>>> future = session.execute_async("SELECT * FROM mycf")
>>> # do other stuff...
>>> try:
... rows = future.result()
... for row in rows:
... ... # process results
... except Exception:
... log.exception("Operation failed:")
"""
self._event.wait()
if self._final_result is not _NOT_SET:
return ResultSet(self, self._final_result)
else:
> raise self._final_exception
E cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client
request timeout. See Session.execute[_async](timeout)'},
last_host=127.0.0.1:9042
../env3.8/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
test_sstableofflinerelevel
FLAKY
offline_tools_test.TestOfflineTools
test_resumable_decommission
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
The failure looks different in Jenkins:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/testReport/junit/dtest-latest.offline_tools_test/TestOfflineTools/Tests___dtest_latest_jdk11_35_64___test_sstablelevelreset/
--
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-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
[
https://issues.apache.org/jira/browse/CASSANDRA-19539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19539:
Component/s: Test/dtest/python
> Test Failure: test_bootstrap_with_reset_bootstrap_state
> ---
>
> Key: CASSANDRA-19539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180
> seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
> TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
> checkLive=true}
> self =
> @since('2.2')
> def test_bootstrap_with_reset_bootstrap_state(self):
> """Test bootstrap with resetting bootstrap progress"""
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(2).start()
>
> node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
> node1.flush()
>
> # kill node1 in the middle of streaming to let it fail
> t = InterruptBootstrap(node1)
> t.start()
>
> # start bootstrapping node3 and wait for streaming
> node3 = new_node(cluster)
> try:
> node3.start()
> except NodeError:
> pass # node doesn't start as expected
> t.join()
> node1.start()
>
> # restart node3 bootstrap with resetting bootstrap progress
> node3.stop(signal_event=signal.SIGKILL)
> mark = node3.mark_log()
> node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
> # check if we reset bootstrap state
> node3.watch_log_for("Resetting bootstrap progress to start fresh",
> from_mark=mark)
> # wait for node3 ready to query, 180s as the node needs to bootstrap
> > node3.wait_for_binary_interface(from_mark=mark, timeout=180)
> bootstrap_test.py:513:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
> wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173092.936025, timeout = 180
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
> node = 'node3'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
> 180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19538:
Component/s: Test/dtest/python
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
[
https://issues.apache.org/jira/browse/CASSANDRA-19539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19539:
Fix Version/s: 5.x
> Test Failure: test_bootstrap_with_reset_bootstrap_state
> ---
>
> Key: CASSANDRA-19539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180
> seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
> TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
> checkLive=true}
> self =
> @since('2.2')
> def test_bootstrap_with_reset_bootstrap_state(self):
> """Test bootstrap with resetting bootstrap progress"""
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(2).start()
>
> node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
> node1.flush()
>
> # kill node1 in the middle of streaming to let it fail
> t = InterruptBootstrap(node1)
> t.start()
>
> # start bootstrapping node3 and wait for streaming
> node3 = new_node(cluster)
> try:
> node3.start()
> except NodeError:
> pass # node doesn't start as expected
> t.join()
> node1.start()
>
> # restart node3 bootstrap with resetting bootstrap progress
> node3.stop(signal_event=signal.SIGKILL)
> mark = node3.mark_log()
> node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
> # check if we reset bootstrap state
> node3.watch_log_for("Resetting bootstrap progress to start fresh",
> from_mark=mark)
> # wait for node3 ready to query, 180s as the node needs to bootstrap
> > node3.wait_for_binary_interface(from_mark=mark, timeout=180)
> bootstrap_test.py:513:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
> wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173092.936025, timeout = 180
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
> node = 'node3'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
> 180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
[
https://issues.apache.org/jira/browse/CASSANDRA-19539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19539:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_bootstrap_with_reset_bootstrap_state
> ---
>
> Key: CASSANDRA-19539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failing on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180
> seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
> TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
> checkLive=true}
> self =
> @since('2.2')
> def test_bootstrap_with_reset_bootstrap_state(self):
> """Test bootstrap with resetting bootstrap progress"""
> cluster = self.cluster
>
> cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
> 'True')
>
> cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
> 1})
> cluster.populate(2).start()
>
> node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
> node1.flush()
>
> # kill node1 in the middle of streaming to let it fail
> t = InterruptBootstrap(node1)
> t.start()
>
> # start bootstrapping node3 and wait for streaming
> node3 = new_node(cluster)
> try:
> node3.start()
> except NodeError:
> pass # node doesn't start as expected
> t.join()
> node1.start()
>
> # restart node3 bootstrap with resetting bootstrap progress
> node3.stop(signal_event=signal.SIGKILL)
> mark = node3.mark_log()
> node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
> # check if we reset bootstrap state
> node3.watch_log_for("Resetting bootstrap progress to start fresh",
> from_mark=mark)
> # wait for node3 ready to query, 180s as the node needs to bootstrap
> > node3.wait_for_binary_interface(from_mark=mark, timeout=180)
> bootstrap_test.py:513:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
> wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173092.936025, timeout = 180
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
> node = 'node3'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
> 180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found
> in system.log:
> EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
> ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_COMMIT_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19539) Test Failure: test_bootstrap_with_reset_bootstrap_state
Ekaterina Dimitrova created CASSANDRA-19539:
---
Summary: Test Failure: test_bootstrap_with_reset_bootstrap_state
Key: CASSANDRA-19539
URL: https://issues.apache.org/jira/browse/CASSANDRA-19539
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failing on trunk:
{code:java}
ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after 180.22/180 seconds
Missing: ['Starting listening for CQL clients'] not found in system.log:
Head: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
Tail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
checkLive=true}
self =
@since('2.2')
def test_bootstrap_with_reset_bootstrap_state(self):
"""Test bootstrap with resetting bootstrap progress"""
cluster = self.cluster
cluster.set_environment_variable('CASSANDRA_TOKEN_PREGENERATION_DISABLED',
'True')
cluster.set_configuration_options(values={'stream_throughput_outbound_megabits_per_sec':
1})
cluster.populate(2).start()
node1 = cluster.nodes['node1']
node1.stress(['write', 'n=100K', '-schema', 'replication(factor=2)'])
node1.flush()
# kill node1 in the middle of streaming to let it fail
t = InterruptBootstrap(node1)
t.start()
# start bootstrapping node3 and wait for streaming
node3 = new_node(cluster)
try:
node3.start()
except NodeError:
pass # node doesn't start as expected
t.join()
node1.start()
# restart node3 bootstrap with resetting bootstrap progress
node3.stop(signal_event=signal.SIGKILL)
mark = node3.mark_log()
node3.start(jvm_args=["-Dcassandra.reset_bootstrap_progress=true"])
# check if we reset bootstrap state
node3.watch_log_for("Resetting bootstrap progress to start fresh",
from_mark=mark)
# wait for node3 ready to query, 180s as the node needs to bootstrap
> node3.wait_for_binary_interface(from_mark=mark, timeout=180)
bootstrap_test.py:513:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:709: in
wait_for_binary_interface
self.watch_log_for("Starting listening for CQL clients", **kwargs)
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
start = 1712173092.936025, timeout = 180
msg = "Missing: ['Starting listening for CQL clients'] not found in
system.log:\n Head: INFO [main] 2024-04-03 19:37:59,845...00: TIMEOUT when
sending TCM_COMMIT_REQ, retrying on
CandidateIterator{candidates=[/127.0.0.1:7000], checkLive=true}\n"
node = 'node3'
@staticmethod
def raise_if_passed(start, timeout, msg, node=None):
if start + timeout < time.time():
> raise TimeoutError.create(start, timeout, msg, node)
E ccmlib.node.TimeoutError: 03 Apr 2024 19:41:13 [node3] after
180.22/180 seconds Missing: ['Starting listening for CQL clients'] not found in
system.log:
EHead: INFO [main] 2024-04-03 19:37:59,845 YamlConfigura
ETail: ...19 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_COMMIT_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000],
checkLive=true}
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19538:
Fix Version/s: 5.x
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19538) Test Failure: test_assassinate_valid_node
[
https://issues.apache.org/jira/browse/CASSANDRA-19538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19538:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_assassinate_valid_node
> -
>
> Key: CASSANDRA-19538
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Failing consistently on trunk:
> {code:java}
> ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120
> seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> Tail: ... some nodes were not ready
> INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484
> - Setup task failed with error, rescheduling
> self =
> def test_assassinate_valid_node(self):
> """
> @jira_ticket CASSANDRA-16588
> Test that after taking two non-seed nodes down and assassinating
> one of them, the other can come back up.
> """
> cluster = self.cluster
>
> cluster.populate(5).start()
> node1 = cluster.nodelist()[0]
> node3 = cluster.nodelist()[2]
>
> self.cluster.set_configuration_options({
> 'seed_provider': [{'class_name':
> 'org.apache.cassandra.locator.SimpleSeedProvider',
>'parameters': [{'seeds': node1.address()}]
> }]
> })
>
> non_seed_nodes = cluster.nodelist()[-2:]
> for node in non_seed_nodes:
> node.stop()
>
> assassination_target = non_seed_nodes[0]
> logger.debug("Assassinating non-seed node
> {}".format(assassination_target.address()))
> out, err, _ = node1.nodetool("assassinate
> {}".format(assassination_target.address()))
> assert_stderr_clean(err)
>
> logger.debug("Starting non-seed nodes")
> for node in non_seed_nodes:
> > node.start()
> gossip_test.py:78:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
> node.watch_log_for_alive(self, from_mark=mark)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in
> watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1712173052.8186479, timeout = 120
> msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n
> Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1]
> 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 - Setup task failed
> with error, rescheduling\n"
> node = 'node1'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
> 120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
> system.log:
> EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
> ETail: ... some nodes were not ready
> E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
> CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
> ../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
> {code}
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19538) Test Failure: test_assassinate_valid_node
Ekaterina Dimitrova created CASSANDRA-19538:
---
Summary: Test Failure: test_assassinate_valid_node
Key: CASSANDRA-19538
URL: https://issues.apache.org/jira/browse/CASSANDRA-19538
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Failing consistently on trunk:
{code:java}
ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after 120.11/120 seconds
Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:
Head: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
Tail: ... some nodes were not ready
INFO [OptionalTasks:1] 2024-04-03 19:39:30,454 CassandraRoleManager.java:484 -
Setup task failed with error, rescheduling
self =
def test_assassinate_valid_node(self):
"""
@jira_ticket CASSANDRA-16588
Test that after taking two non-seed nodes down and assassinating
one of them, the other can come back up.
"""
cluster = self.cluster
cluster.populate(5).start()
node1 = cluster.nodelist()[0]
node3 = cluster.nodelist()[2]
self.cluster.set_configuration_options({
'seed_provider': [{'class_name':
'org.apache.cassandra.locator.SimpleSeedProvider',
'parameters': [{'seeds': node1.address()}]
}]
})
non_seed_nodes = cluster.nodelist()[-2:]
for node in non_seed_nodes:
node.stop()
assassination_target = non_seed_nodes[0]
logger.debug("Assassinating non-seed node
{}".format(assassination_target.address()))
out, err, _ = node1.nodetool("assassinate
{}".format(assassination_target.address()))
assert_stderr_clean(err)
logger.debug("Starting non-seed nodes")
for node in non_seed_nodes:
> node.start()
gossip_test.py:78:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:915: in start
node.watch_log_for_alive(self, from_mark=mark)
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:684: in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:608: in watch_log_for
TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
start = 1712173052.8186479, timeout = 120
msg = "Missing: ['127.0.0.4:7000.* is now UP'] not found in system.log:\n Head:
INFO [Messaging-EventLoop-3-1] 2024-04-03 1...[OptionalTasks:1] 2024-04-03
19:39:30,454 CassandraRoleManager.java:484 - Setup task failed with error,
rescheduling\n"
node = 'node1'
@staticmethod
def raise_if_passed(start, timeout, msg, node=None):
if start + timeout < time.time():
> raise TimeoutError.create(start, timeout, msg, node)
E ccmlib.node.TimeoutError: 03 Apr 2024 19:39:32 [node1] after
120.11/120 seconds Missing: ['127.0.0.4:7000.* is now UP'] not found in
system.log:
EHead: INFO [Messaging-EventLoop-3-1] 2024-04-03 19:37:3
ETail: ... some nodes were not ready
E INFO [OptionalTasks:1] 2024-04-03 19:39:30,454
CassandraRoleManager.java:484 - Setup task failed with error, rescheduling
../env3.8/lib/python3.8/site-packages/ccmlib/node.py:56: TimeoutError
{code}
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-0
https://ci-cassandra.apache.org/job/Cassandra-trunk/1859/#showFailuresLink
--
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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833770#comment-17833770 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - Tickets opened and linked here: !https://issues.apache.org/jira/secure/viewavatar?size=xsmall=21133=issuetype|width=16,height=16! CASSANDRA-19522 Test Failure: test_simple_decommission !https://issues.apache.org/jira/secure/viewavatar?size=xsmall=21133=issuetype|width=16,height=16! CASSANDRA-19523 Test Failure: testMixedVersionBlockDecom !https://issues.apache.org/jira/secure/viewavatar?size=xsmall=21133=issuetype|width=16,height=16! CASSANDRA-19524 Test Failure: testIncompleteState > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19524) Test Failure: testIncompleteState
[
https://issues.apache.org/jira/browse/CASSANDRA-19524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19524:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: testIncompleteState
> -
>
> Key: CASSANDRA-19524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19524
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58956/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.gms.NewGossiperTest.testIncompleteState(NewGossiperTest.java:141)
> 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){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-19524) Test Failure: testIncompleteState
[
https://issues.apache.org/jira/browse/CASSANDRA-19524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19524:
Fix Version/s: 5.x
> Test Failure: testIncompleteState
> -
>
> Key: CASSANDRA-19524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19524
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58956/tests#failed-test-0]
> {code:java}
> junit.framework.AssertionFailedError at
> org.apache.cassandra.gms.NewGossiperTest.testIncompleteState(NewGossiperTest.java:141)
> 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){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-19524) Test Failure: testIncompleteState
Ekaterina Dimitrova created CASSANDRA-19524:
---
Summary: Test Failure: testIncompleteState
Key: CASSANDRA-19524
URL: https://issues.apache.org/jira/browse/CASSANDRA-19524
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58956/tests#failed-test-0]
{code:java}
junit.framework.AssertionFailedError at
org.apache.cassandra.gms.NewGossiperTest.testIncompleteState(NewGossiperTest.java:141)
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){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-19523) Test Failure: testMixedVersionBlockDecom
[
https://issues.apache.org/jira/browse/CASSANDRA-19523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19523:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: testMixedVersionBlockDecom
>
>
> Key: CASSANDRA-19523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19523
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58954/tests#failed-test-0]
> {code:java}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79) at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:546) at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.distributed.test.ring.DecommissionTest.testMixedVersionBlockDecom(DecommissionTest.java:173)
> 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: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:538){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-19523) Test Failure: testMixedVersionBlockDecom
[
https://issues.apache.org/jira/browse/CASSANDRA-19523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19523:
Fix Version/s: 5.x
> Test Failure: testMixedVersionBlockDecom
>
>
> Key: CASSANDRA-19523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19523
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58954/tests#failed-test-0]
> {code:java}
> java.lang.RuntimeException: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79) at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:546) at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
> at
> org.apache.cassandra.distributed.test.ring.DecommissionTest.testMixedVersionBlockDecom(DecommissionTest.java:173)
> 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: java.util.concurrent.TimeoutException at
> org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
> at
> org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:538){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-19523) Test Failure: testMixedVersionBlockDecom
Ekaterina Dimitrova created CASSANDRA-19523:
---
Summary: Test Failure: testMixedVersionBlockDecom
Key: CASSANDRA-19523
URL: https://issues.apache.org/jira/browse/CASSANDRA-19523
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58954/tests#failed-test-0]
{code:java}
java.lang.RuntimeException: java.util.concurrent.TimeoutException at
org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79) at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:546) at
org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
at
org.apache.cassandra.distributed.test.ring.DecommissionTest.testMixedVersionBlockDecom(DecommissionTest.java:173)
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: java.util.concurrent.TimeoutException at
org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
at
org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:538){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-19522) Test Failure: test_simple_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19522:
Fix Version/s: 5.x
> Test Failure: test_simple_decommission
> --
>
> Key: CASSANDRA-19522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19522
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Locally it fails for me:
> test_simple_decommission failed; it passed 0 out of the required 1 times.
>
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
> exited with non-zero status; exit status: 1;
> stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
> nodes to maintain replication factor after decommission.).
> See 'nodetool help' or 'nodetool help '.
> It failed in CircleCI in a different way once and I cannot reproduce it
> anymore in CircleCI. It passed many times there:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03
> 19:44:52,473 MessagingService.java:501 - Cannot send the message
> (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN) to
> /127.0.0.1:7000, as messaging service is shutting down']" Unexpected error
> found in node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [GossipTasks:1] 2024-04-03 19:44:52,473 MessagingService.java:501 - Cannot
> send the message (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN)
> to /127.0.0.1:7000, as messaging service is shutting down']{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-19522) Test Failure: test_simple_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19522:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure: test_simple_decommission
> --
>
> Key: CASSANDRA-19522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19522
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Locally it fails for me:
> test_simple_decommission failed; it passed 0 out of the required 1 times.
>
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
> exited with non-zero status; exit status: 1;
> stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
> nodes to maintain replication factor after decommission.).
> See 'nodetool help' or 'nodetool help '.
> It failed in CircleCI in a different way once and I cannot reproduce it
> anymore in CircleCI. It passed many times there:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03
> 19:44:52,473 MessagingService.java:501 - Cannot send the message
> (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN) to
> /127.0.0.1:7000, as messaging service is shutting down']" Unexpected error
> found in node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [GossipTasks:1] 2024-04-03 19:44:52,473 MessagingService.java:501 - Cannot
> send the message (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN)
> to /127.0.0.1:7000, as messaging service is shutting down']{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-19522) Test Failure: test_simple_decommission
Ekaterina Dimitrova created CASSANDRA-19522:
---
Summary: Test Failure: test_simple_decommission
Key: CASSANDRA-19522
URL: https://issues.apache.org/jira/browse/CASSANDRA-19522
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Locally it fails for me:
test_simple_decommission failed; it passed 0 out of the required 1 times.
Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
exited with non-zero status; exit status: 1;
stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
nodes to maintain replication factor after decommission.).
See 'nodetool help' or 'nodetool help '.
It failed in CircleCI in a different way once and I cannot reproduce it anymore
in CircleCI. It passed many times there:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
{code:java}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03 19:44:52,473
MessagingService.java:501 - Cannot send the message (from:/127.0.0.2:7000,
type:GOSSIP verb:GOSSIP_DIGEST_SYN) to /127.0.0.1:7000, as messaging service is
shutting down']" Unexpected error found in node logs (see stdout for full
details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03 19:44:52,473
MessagingService.java:501 - Cannot send the message (from:/127.0.0.2:7000,
type:GOSSIP verb:GOSSIP_DIGEST_SYN) to /127.0.0.1:7000, as messaging service is
shutting down']{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-19522) Test Failure: test_simple_decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-19522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-19522:
Description:
Locally it fails for me:
{code:java}
test_simple_decommission failed; it passed 0 out of the required 1 times.
Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission'] exited
with non-zero status; exit status: 1;
stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
nodes to maintain replication factor after decommission.).
See 'nodetool help' or 'nodetool help '.{code}
It failed in CircleCI in a different way once and I cannot reproduce it anymore
in CircleCI. It passed many times there:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
{code:java}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03 19:44:52,473
MessagingService.java:501 - Cannot send the message (from:/127.0.0.2:7000,
type:GOSSIP verb:GOSSIP_DIGEST_SYN) to /127.0.0.1:7000, as messaging service is
shutting down']" Unexpected error found in node logs (see stdout for full
details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03 19:44:52,473
MessagingService.java:501 - Cannot send the message (from:/127.0.0.2:7000,
type:GOSSIP verb:GOSSIP_DIGEST_SYN) to /127.0.0.1:7000, as messaging service is
shutting down']{code}
was:
Locally it fails for me:
test_simple_decommission failed; it passed 0 out of the required 1 times.
Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
exited with non-zero status; exit status: 1;
stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
nodes to maintain replication factor after decommission.).
See 'nodetool help' or 'nodetool help '.
It failed in CircleCI in a different way once and I cannot reproduce it anymore
in CircleCI. It passed many times there:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
{code:java}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03 19:44:52,473
MessagingService.java:501 - Cannot send the message (from:/127.0.0.2:7000,
type:GOSSIP verb:GOSSIP_DIGEST_SYN) to /127.0.0.1:7000, as messaging service is
shutting down']" Unexpected error found in node logs (see stdout for full
details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03 19:44:52,473
MessagingService.java:501 - Cannot send the message (from:/127.0.0.2:7000,
type:GOSSIP verb:GOSSIP_DIGEST_SYN) to /127.0.0.1:7000, as messaging service is
shutting down']{code}
> Test Failure: test_simple_decommission
> --
>
> Key: CASSANDRA-19522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19522
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Locally it fails for me:
> {code:java}
> test_simple_decommission failed; it passed 0 out of the required 1 times.
>
> Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
> exited with non-zero status; exit status: 1;
> stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
> nodes to maintain replication factor after decommission.).
> See 'nodetool help' or 'nodetool help '.{code}
> It failed in CircleCI in a different way once and I cannot reproduce it
> anymore in CircleCI. It passed many times there:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2680/workflows/8b1c0d0a-7458-4b43-9bba-ac96b9bfe64f/jobs/58929/tests#failed-test-5]
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [GossipTasks:1] 2024-04-03
> 19:44:52,473 MessagingService.java:501 - Cannot send the message
> (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN) to
> /127.0.0.1:7000, as messaging service is shutting down']" Unexpected error
> found in node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [GossipTasks:1] 2024-04-03 19:44:52,473 MessagingService.java:501 - Cannot
> send the message (from:/127.0.0.2:7000, type:GOSSIP verb:GOSSIP_DIGEST_SYN)
> to /127.0.0.1:7000, as messaging service is shutting down']{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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Source Control Link: https://github.com/apache/cassandra/commit/b0150e86fbf5863fd831cfca8118f1a8bd254a43. https://github.com/apache/cassandra/commit/a1b0a310eded202d86d6fd0f746a5176ff8cabbe (was: https://github.com/apache/cassandra/commit/b0150e86fbf5863fd831cfca8118f1a8bd254a43) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Fix Version/s: 5.0-beta2 5.1-alpha 5.1 (was: 5.x) (was: 5.0-rc) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha, 5.1 > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Source Control Link: https://github.com/apache/cassandra/commit/b0150e86fbf5863fd831cfca8118f1a8bd254a43 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[
https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833767#comment-17833767
]
Ekaterina Dimitrova commented on CASSANDRA-19428:
-
I cannot reproduce the failures with or without the patch. Those tests are
added to trunk with TCM, so I am not worried we could have broken them with
this SAI patch.
I will commit the current patch and open follow-up tickets for
test_simple_decommission, testMixedVersionBlockDecom, testIncompleteState.
Test_simple_decommission actually fails in a different way locally, both with
trunk and the current patch:
{code:java}
test_simple_decommission failed; it passed 0 out of the required 1 times.
Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'decommission']
exited with non-zero status; exit status: 1;
stdout: nodetool: Can not commit transformation: "INVALID"(Not enough live
nodes to maintain replication factor after decommission.).
See 'nodetool help' or 'nodetool help '.
{code}
Committed:
To https://github.com/apache/cassandra.git
973aad7b68..b0150e86fb cassandra-5.0 -> cassandra-5.0
2944d77aac..a1b0a310ed trunk -> trunk
> Clean up KeyRangeIterator classes
> -
>
> Key: CASSANDRA-19428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Remove KeyRangeIterator.current and simplify
--
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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833748#comment-17833748 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 4/3/24 9:57 PM: - Update: CASSANDRA-14572 was committed just after I rebased. This means the cassandra patch was not presented during the CI run, but the cassandra-dtest was presented. This leads to test_default_keyspaces_exist failing. After rebase (with no conflicts) the test does not fail for me locally anymore. Most of the failures here are also presented in the final CASSANDRA-14572 CI run: test_assassinate_valid_node - CASSANDRA-18753 test_bootstrap_with_reset_bootstrap_state - (?) test_sstablelevelreset - (?) test_sstableofflinerelevel - (?) test_resumable_decommission - (?) testConcurrentReadWriteWorkload-_jdk11 - seen in Butler but I did not find a ticket (?) simulationTest - (?) testSplitBrainStartup-_jdk17 - (?) discoveryTest - failed also with 14572 CI run, attributed to network glitch ([https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/31fe6cd5-e653-46f3-b44c-113568e275cf/jobs/79487/tests#failed-test-0)] - ticket (?) [~mmuzaf] , are those marked with (?) in my list ticketed? I did not find a trace in Jira, except they were presented in your CI run from CASSANDRA-14572. Failures not presented on that run, trying to reproduce them now, but they do not seem related in any way to what we do here. Plus 5.0 is clean run and the SAI code is almost identical in 5.0 and trunk. test_simple_decommission - testMixedVersionBlockDecom-_jdk17 - testIncompleteState-oa_jdk17 - I will update soon about these last 3 was (Author: e.dimitrova): Update: CASSANDRA-14572 was committed just after I rebased. This means the cassandra patch was not presented during the CI run, but the cassandra-dtest was presented. This lead to test_default_keyspaces_exist failing. After rebase (with no conflicts) the test does not fail for me locally anymore. The rest of the failures here are also presented in the final CASSANDRA-14572 CI run: test_assassinate_valid_node - CASSANDRA-18753 test_bootstrap_with_reset_bootstrap_state - (?) test_sstablelevelreset - (?) test_sstableofflinerelevel - (?) test_resumable_decommission - (?) testConcurrentReadWriteWorkload-_jdk11 - seen in Butler but I did not find a ticket (?) simulationTest - (?) testSplitBrainStartup-_jdk17 - (?) discoveryTest - failed also with 14572 CI run, attributed to network glitch ([https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/31fe6cd5-e653-46f3-b44c-113568e275cf/jobs/79487/tests#failed-test-0)] - ticket (?) [~mmuzaf] , are those marked with (?) in my list ticketed? I did not find a trace in Jira, except they were presented in your CI run from CASSANDRA-14572. Failures not presented on that run, trying to reproduce them now, but they do not seem related in any way to what we do here. Plus 5.0 is clean run and the SAI code is almost identical in 5.0 and trunk. test_simple_decommission - testMixedVersionBlockDecom-_jdk17 - testIncompleteState-oa_jdk17 - I will update soon about these last 3 > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833748#comment-17833748 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 4/3/24 9:33 PM: - Update: CASSANDRA-14572 was committed just after I rebased. This means the cassandra patch was not presented during the CI run, but the cassandra-dtest was presented. This lead to test_default_keyspaces_exist failing. After rebase (with no conflicts) the test does not fail for me locally anymore. The rest of the failures here are also presented in the final CASSANDRA-14572 CI run: test_assassinate_valid_node - CASSANDRA-18753 test_bootstrap_with_reset_bootstrap_state - (?) test_sstablelevelreset - (?) test_sstableofflinerelevel - (?) test_resumable_decommission - (?) testConcurrentReadWriteWorkload-_jdk11 - seen in Butler but I did not find a ticket (?) simulationTest - (?) testSplitBrainStartup-_jdk17 - (?) discoveryTest - failed also with 14572 CI run, attributed to network glitch ([https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/31fe6cd5-e653-46f3-b44c-113568e275cf/jobs/79487/tests#failed-test-0)] - ticket (?) [~mmuzaf] , are those marked with (?) in my list ticketed? I did not find a trace in Jira, except they were presented in your CI run from CASSANDRA-14572. Failures not presented on that run, trying to reproduce them now, but they do not seem related in any way to what we do here. Plus 5.0 is clean run and the SAI code is almost identical in 5.0 and trunk. test_simple_decommission - testMixedVersionBlockDecom-_jdk17 - testIncompleteState-oa_jdk17 - I will update soon about these last 3 was (Author: e.dimitrova): Update: CASSANDRA-14572 was committed just after I rebased. This means the cassandra patch was not presented during the CI run, but the cassandra-dtest was presented. This lead to test_default_keyspaces_exist failing. After rebase (with no conflicts) the test does not fail for me locally anymore. The rest of the failures here are also presented in the final CASSANDRA-14572 CI run: test_assassinate_valid_node - CASSANDRA-18753 test_bootstrap_with_reset_bootstrap_state - (?) test_sstablelevelreset - (?) test_sstableofflinerelevel - (?) test_resumable_decommission - (?) testConcurrentReadWriteWorkload-_jdk11 - seen in Butler but I did not find a ticket (?) simulationTest - (?) testSplitBrainStartup-_jdk17 - (?) discoveryTest - failed also with 14572 CI run, attributed to network glitch ([https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/31fe6cd5-e653-46f3-b44c-113568e275cf/jobs/79487/tests#failed-test-0)] - ticket (?) [~mmuzaf] , are those marked with ? in my list ticketed? I did not find a trace in Jira, except they were presented in your CI run from CASSANDRA-14572. Failures not presented on that run, trying to reproduce them now, but they do not seem related in any way to what we do here. Plus 5.0 is clean run and the SAI code is almost identical in 5.0 and trunk. test_simple_decommission - testMixedVersionBlockDecom-_jdk17 - testIncompleteState-oa_jdk17 - I will update soon about these last 3 > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833748#comment-17833748 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - Update: CASSANDRA-14572 was committed just after I rebased. This means the cassandra patch was not presented during the CI run, but the cassandra-dtest was presented. This lead to test_default_keyspaces_exist failing. After rebase (with no conflicts) the test does not fail for me locally anymore. The rest of the failures here are also presented in the final CASSANDRA-14572 CI run: test_assassinate_valid_node - CASSANDRA-18753 test_bootstrap_with_reset_bootstrap_state - (?) test_sstablelevelreset - (?) test_sstableofflinerelevel - (?) test_resumable_decommission - (?) testConcurrentReadWriteWorkload-_jdk11 - seen in Butler but I did not find a ticket (?) simulationTest - (?) testSplitBrainStartup-_jdk17 - (?) discoveryTest - failed also with 14572 CI run, attributed to network glitch ([https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/31fe6cd5-e653-46f3-b44c-113568e275cf/jobs/79487/tests#failed-test-0)] - ticket (?) [~mmuzaf] , are those marked with ? in my list ticketed? I did not find a trace in Jira, except they were presented in your CI run from CASSANDRA-14572. Failures not presented on that run, trying to reproduce them now, but they do not seem related in any way to what we do here. Plus 5.0 is clean run and the SAI code is almost identical in 5.0 and trunk. test_simple_decommission - testMixedVersionBlockDecom-_jdk17 - testIncompleteState-oa_jdk17 - I will update soon about these last 3 > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833718#comment-17833718 ] Ekaterina Dimitrova commented on CASSANDRA-19428: - 5.0, fully green: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19428-5.0-final trunk, still in progress: https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=C19428-trunk-final > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[
https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833661#comment-17833661
]
Ekaterina Dimitrova commented on CASSANDRA-19428:
-
Update: [~adelapena] won't have the chance to review this one.
{quote}The trunk branch has survived a good 20-minute assault from
{{{}MultiNodeSAITest{}}}.
{quote}
Considering this and that two committers are already involved, we agreed to
move forward with squash, full pre-commit tests run confirmation, and commit. I
will post the CI runs shortly.
> Clean up KeyRangeIterator classes
> -
>
> Key: CASSANDRA-19428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/2i Index
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Remove KeyRangeIterator.current and simplify
--
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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Reviewers: Caleb Rackliffe, Ekaterina Dimitrova (was: Andres de la Peña, Caleb Rackliffe, Ekaterina Dimitrova) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Reviewers: Andres de la Peña, Caleb Rackliffe, Ekaterina Dimitrova (was: Andres de la Peña, Caleb Rackliffe, Ekaterina Dimitrova) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832956#comment-17832956 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 4/3/24 12:04 AM: -- Latest rebased branch that fixes the tests (the last small commit): [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] Applied also to trunk: [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I am running CI now. EDIT: CI did not show any new failures to both 5.0 and trunk - I ran the skinny dev preliminary testing After final review round from [~adelapena] I will submit the full pre-commit results here. was (Author: e.dimitrova): Latest branch that fixes the tests: [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] Applied also to trunk: [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I am running CI now. EDIT: CI did not show any new failures to both 5.0 and trunk - I ran the skinny dev preliminary testing After final review round from [~adelapena] I will submit the full pre-commit results here. > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Test and Documentation Plan: -5.0 patch PR - [https://github.com/apache/cassandra/pull/3194]- --Fully green CI -- [-https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19428-5.0-3-]- Latest branches: [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I tested locally the patch on top of the trunk - running the new fuzz tests added, and they all passed, too. I can propagate and run full CI when we confirm the final patch. Clean up KeyRangeIterator classes * replace KeyRangeConcatIterator's PriorityQeueu with List * remove KeyRangeIterator.current and simplify * remove injected exception and tests - not relevant to the current implementation * expand randomized testing * inline getCurrent() -> peek(); rename getCount to getMaxKeys * redefine skipTo contract to not return a value (which saves unnecessary work when skipTo is called multiple times in a row) * calling hasNext in skipTo is a pessimization; if the iterator is in DONE state, then skipTo will see it and avoid further effort; if it is not, then we are computing a next value that we're just going to throw away * Fix a bug in QueryController#getIndexResults error handling was: -5.0 patch PR - [https://github.com/apache/cassandra/pull/3194]- -Fully green CI -- [-https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19428-5.0-3-] Latest branches: [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I tested locally the patch on top of the trunk - running the new fuzz tests added, and they all passed, too. I can propagate and run full CI when we confirm the final patch. Clean up KeyRangeIterator classes * replace KeyRangeConcatIterator's PriorityQeueu with List * remove KeyRangeIterator.current and simplify * remove injected exception and tests - not relevant to the current implementation * expand randomized testing * inline getCurrent() -> peek(); rename getCount to getMaxKeys * redefine skipTo contract to not return a value (which saves unnecessary work when skipTo is called multiple times in a row) * calling hasNext in skipTo is a pessimization; if the iterator is in DONE state, then skipTo will see it and avoid further effort; if it is not, then we are computing a next value that we're just going to throw away * Fix a bug in QueryController#getIndexResults error handling > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Reviewers: Andres de la Peña, Caleb Rackliffe, Ekaterina Dimitrova (was: Caleb Rackliffe) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Test and Documentation Plan: -5.0 patch PR - [https://github.com/apache/cassandra/pull/3194]- -Fully green CI -- [-https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19428-5.0-3-] Latest branches: [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I tested locally the patch on top of the trunk - running the new fuzz tests added, and they all passed, too. I can propagate and run full CI when we confirm the final patch. Clean up KeyRangeIterator classes * replace KeyRangeConcatIterator's PriorityQeueu with List * remove KeyRangeIterator.current and simplify * remove injected exception and tests - not relevant to the current implementation * expand randomized testing * inline getCurrent() -> peek(); rename getCount to getMaxKeys * redefine skipTo contract to not return a value (which saves unnecessary work when skipTo is called multiple times in a row) * calling hasNext in skipTo is a pessimization; if the iterator is in DONE state, then skipTo will see it and avoid further effort; if it is not, then we are computing a next value that we're just going to throw away * Fix a bug in QueryController#getIndexResults error handling was: 5.0 patch PR - [https://github.com/apache/cassandra/pull/3194] Fully green CI - [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=19428-5.0-3] I tested locally the patch on top of the trunk - running the new fuzz tests added, and they all passed, too. I can propagate and run full CI when we confirm the final patch. Clean up KeyRangeIterator classes * replace KeyRangeConcatIterator's PriorityQeueu with List * remove KeyRangeIterator.current and simplify * remove injected exception and tests - not relevant to the current implementation * expand randomized testing * inline getCurrent() -> peek(); rename getCount to getMaxKeys * redefine skipTo contract to not return a value (which saves unnecessary work when skipTo is called multiple times in a row) * calling hasNext in skipTo is a pessimization; if the iterator is in DONE state, then skipTo will see it and avoid further effort; if it is not, then we are computing a next value that we're just going to throw away * Fix a bug in QueryController#getIndexResults error handling > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-19428: Authors: Caleb Rackliffe, Ekaterina Dimitrova, Jonathan Ellis, Michael Marshall, Piotr Kolaczkowski (was: Caleb Rackliffe, Ekaterina Dimitrova) > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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-19428) Clean up KeyRangeIterator classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832956#comment-17832956 ] Ekaterina Dimitrova edited comment on CASSANDRA-19428 at 4/2/24 2:23 PM: - Latest branch that fixes the tests: [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] Applied also to trunk: [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I am running CI now. EDIT: CI did not show any new failures to both 5.0 and trunk - I ran the skinny dev preliminary testing After final review round from [~adelapena] I will submit the full pre-commit results here. was (Author: e.dimitrova): Latest branch that fixes the tests: [https://github.com/ekaterinadimitrova2/cassandra/tree/19428-5.0-5] Applied also to trunk: [https://github.com/ekaterinadimitrova2/cassandra/pull/new/19428-trunk-2] I am running CI now. > Clean up KeyRangeIterator classes > - > > Key: CASSANDRA-19428 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19428 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0-rc, 5.x > > Attachments: > Make_sure_the_builders_attach_the_onClose_hook_when_there_is_only_a_single_sub-iterator.patch > > Time Spent: 3h > Remaining Estimate: 0h > > Remove KeyRangeIterator.current and simplify -- 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
