[jira] [Commented] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598169#comment-17598169
]
Leonard Ma commented on CASSANDRA-17668:
I don't really have a preference on this one and am okay with whatever we
decide
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
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-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598169#comment-17598169
]
Leonard Ma edited comment on CASSANDRA-17668 at 8/31/22 4:53 AM:
-
I don't really have a preference and am okay with whatever we decide
was (Author: JIRAUSER292010):
I don't really have a preference on this one and am okay with whatever we
decide
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
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-17857) upsert with adder support is not consistent with numbers and strings in LWT
[
https://issues.apache.org/jira/browse/CASSANDRA-17857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598156#comment-17598156
]
Caleb Rackliffe commented on CASSANDRA-17857:
-
+1 (with a minor comment on the new test)
> upsert with adder support is not consistent with numbers and strings in LWT
> ---
>
> Key: CASSANDRA-17857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17857
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics, Feature/Lightweight Transactions
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In 4.1 UPDATE name = name + offset support got extended to numbers and
> strings (not just counters) but the behavior isn’t consistent
> Number: throws a error due to Int32Type.add(null, 42) failing
> String: returns the non-null updated values
> What Postgres does is keeps the value null
> {code}
> postgres=# create table x (pk int PRIMARY KEY, a int, b text);
> CREATE TABLE
> postgres=# insert into x (pk, a, b) values(0, null, null);
> INSERT 0 1
> postgres=# UPDATE x SET a = a + 1 WHERE pk = 0;
> UPDATE 1
> postgres=# select * from x;
> pk | a | b
> +---+---
> 0 | |
> (1 row)
> postgres=# UPDATE x SET b = b + 'one' WHERE pk = 0;
> ERROR: operator does not exist: text + unknown
> LINE 1: UPDATE x SET b = b + 'one' WHERE pk = 0;
>^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
> postgres=# UPDATE x SET b = b + CAST('one' as text) WHERE pk = 0;
> ERROR: operator does not exist: text + text
> LINE 1: UPDATE x SET b = b + CAST('one' as text) WHERE pk = 0;
>^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (601902293 -> 7cb4bcf2e)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 601902293 generate docs for 538513bd new 7cb4bcf2e generate docs for 538513bd This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (601902293) \ N -- N -- N refs/heads/asf-staging (7cb4bcf2e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17870) nodetool/rebuild: Add flag to exclude nodes from local datacenter
[ https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-17870: --- Summary: nodetool/rebuild: Add flag to exclude nodes from local datacenter (was: nodetool/rebuild: C* rebuilds from local (new dc) dc nodes if src-dc is not passed) > nodetool/rebuild: Add flag to exclude nodes from local datacenter > - > > Key: CASSANDRA-17870 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17870 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild > the data from other DCs. If src-dc is not passed explicitly, then C* tries to > rebuild the data from the same (new dc) dc. > We don’t exclude other nodes in the same DC. Only down sources and the local > node itself are excluded. > ``` > // We're _always_ filtering out a local node and down sources > addSourceFilter(new > RangeStreamer.FailureDetectorSourceFilter(failureDetector)); > addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter()); > ``` > We should fix nodetool/rebuild to exclude the local DC (from where we’re > executing the command) while issuing nodetool/rebuild without passing src dc -- 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-17870) nodetool/rebuild: C* rebuilds from local (new dc) dc nodes if src-dc is not passed
[ https://issues.apache.org/jira/browse/CASSANDRA-17870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saranya Krishnakumar updated CASSANDRA-17870: - Change Category: Operability Complexity: Low Hanging Fruit Component/s: Tool/nodetool Status: Open (was: Triage Needed) > nodetool/rebuild: C* rebuilds from local (new dc) dc nodes if src-dc is not > passed > -- > > Key: CASSANDRA-17870 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17870 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild > the data from other DCs. If src-dc is not passed explicitly, then C* tries to > rebuild the data from the same (new dc) dc. > We don’t exclude other nodes in the same DC. Only down sources and the local > node itself are excluded. > ``` > // We're _always_ filtering out a local node and down sources > addSourceFilter(new > RangeStreamer.FailureDetectorSourceFilter(failureDetector)); > addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter()); > ``` > We should fix nodetool/rebuild to exclude the local DC (from where we’re > executing the command) while issuing nodetool/rebuild without passing src dc -- 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-17870) nodetool/rebuild: C* rebuilds from local (new dc) dc nodes if src-dc is not passed
Saranya Krishnakumar created CASSANDRA-17870: Summary: nodetool/rebuild: C* rebuilds from local (new dc) dc nodes if src-dc is not passed Key: CASSANDRA-17870 URL: https://issues.apache.org/jira/browse/CASSANDRA-17870 Project: Cassandra Issue Type: Improvement Reporter: Saranya Krishnakumar Assignee: Saranya Krishnakumar During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild the data from other DCs. If src-dc is not passed explicitly, then C* tries to rebuild the data from the same (new dc) dc. We don’t exclude other nodes in the same DC. Only down sources and the local node itself are excluded. ``` // We're _always_ filtering out a local node and down sources addSourceFilter(new RangeStreamer.FailureDetectorSourceFilter(failureDetector)); addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter()); ``` We should fix nodetool/rebuild to exclude the local DC (from where we’re executing the command) while issuing nodetool/rebuild without passing src dc -- 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-17857) upsert with adder support is not consistent with numbers and strings in LWT
[
https://issues.apache.org/jira/browse/CASSANDRA-17857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598110#comment-17598110
]
David Capwell commented on CASSANDRA-17857:
---
Mail thread on this topic:
https://lists.apache.org/thread/jy8rodzhxz6zrb4k6trnho2w3bl3kxf1
> upsert with adder support is not consistent with numbers and strings in LWT
> ---
>
> Key: CASSANDRA-17857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17857
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics, Feature/Lightweight Transactions
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In 4.1 UPDATE name = name + offset support got extended to numbers and
> strings (not just counters) but the behavior isn’t consistent
> Number: throws a error due to Int32Type.add(null, 42) failing
> String: returns the non-null updated values
> What Postgres does is keeps the value null
> {code}
> postgres=# create table x (pk int PRIMARY KEY, a int, b text);
> CREATE TABLE
> postgres=# insert into x (pk, a, b) values(0, null, null);
> INSERT 0 1
> postgres=# UPDATE x SET a = a + 1 WHERE pk = 0;
> UPDATE 1
> postgres=# select * from x;
> pk | a | b
> +---+---
> 0 | |
> (1 row)
> postgres=# UPDATE x SET b = b + 'one' WHERE pk = 0;
> ERROR: operator does not exist: text + unknown
> LINE 1: UPDATE x SET b = b + 'one' WHERE pk = 0;
>^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
> postgres=# UPDATE x SET b = b + CAST('one' as text) WHERE pk = 0;
> ERROR: operator does not exist: text + text
> LINE 1: UPDATE x SET b = b + CAST('one' as text) WHERE pk = 0;
>^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598109#comment-17598109
]
David Capwell commented on CASSANDRA-17668:
---
bq. If it is only trunk probably it is fine to just fix it there
If the concern is backwards compatibility then the arguments don't go away
because its trunk... I am cool fixing or adding new and marking old as
Deprecated; will leave it up to [~e.dimitrova] and [~lmtrombone].
bq. I wanted to go for the deprecation because of the old versions
Well, I guess I would ask "when do we want to remove them?" To me trunk is
currently 4.2 so earliest we could drop is 5.0 (or was it 6.0? Forget exactly
what we agreed in terms of minor and Deprecated)... back porting to add the
Deprecated doesn't change that...
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
>
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
>Reporter: Ekaterina Dimitrova
>Assignee: Leonard Ma
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
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-17857) upsert with adder support is not consistent with numbers and strings in LWT
[
https://issues.apache.org/jira/browse/CASSANDRA-17857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17857:
--
Reviewers: Benedict Elliott Smith, Caleb Rackliffe (was: Caleb Rackliffe)
> upsert with adder support is not consistent with numbers and strings in LWT
> ---
>
> Key: CASSANDRA-17857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17857
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics, Feature/Lightweight Transactions
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In 4.1 UPDATE name = name + offset support got extended to numbers and
> strings (not just counters) but the behavior isn’t consistent
> Number: throws a error due to Int32Type.add(null, 42) failing
> String: returns the non-null updated values
> What Postgres does is keeps the value null
> {code}
> postgres=# create table x (pk int PRIMARY KEY, a int, b text);
> CREATE TABLE
> postgres=# insert into x (pk, a, b) values(0, null, null);
> INSERT 0 1
> postgres=# UPDATE x SET a = a + 1 WHERE pk = 0;
> UPDATE 1
> postgres=# select * from x;
> pk | a | b
> +---+---
> 0 | |
> (1 row)
> postgres=# UPDATE x SET b = b + 'one' WHERE pk = 0;
> ERROR: operator does not exist: text + unknown
> LINE 1: UPDATE x SET b = b + 'one' WHERE pk = 0;
>^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
> postgres=# UPDATE x SET b = b + CAST('one' as text) WHERE pk = 0;
> ERROR: operator does not exist: text + text
> LINE 1: UPDATE x SET b = b + CAST('one' as text) WHERE pk = 0;
>^
> HINT: No operator matches the given name and argument types. You might need
> to add explicit type casts.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598079#comment-17598079 ] Ekaterina Dimitrova commented on CASSANDRA-16895: - As per [this mail|https://lists.apache.org/thread/dd0qhsvg2s64kqyfpk4ny8moshyrlc8j] on the dev list I have sent an email to subscribe myself to the quality-discuss mailing list and then I can add the project to the Quality Outreach Program as per [these instructions|https://wiki.openjdk.org/display/quality/Quality+Outreach]. Still waiting for my subscription to be approved. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > 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 -- 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-16413) Byteman fails to install injections after Jacoco upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-16413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598076#comment-17598076 ] Ekaterina Dimitrova commented on CASSANDRA-16413: - I don't think there are concerns too. I just noticed this ticket and it was assigned still to 4.0 when it seems not all dependencies were in a state to support the goal a year ago. It seems things matured and now that changed, so double-checking what others think. I already marked the ticket as 4.x and we can just use the opportunity when we do the switch in Jenkins to J11 also to enable the code coverage if we still want it and see value in that. > Byteman fails to install injections after Jacoco upgrade > > > Key: CASSANDRA-16413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16413 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > This ticket is a follow up on CASSANDRA-16365 and it should be worked on > after the Jacoco upgrade is committed > List of the failing tests: > org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.testCompressedCommitLogBackpressure > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testSSTableNotEnoughDiskSpaceForCompactionGetsDropped > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testRuntimeExceptionWhenNoDiskSpaceForCompaction > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopUserDefinedCompactionRepaired > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopSubRangeCompactionRepaired > org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction > org.apache.cassandra.gms.PendingRangeCalculatorServiceTest.testDelayedResponse > org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure > -- 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] (CASSANDRASC-42) Introduce new handler for Keyspaces/ColumnFamily operations
[ https://issues.apache.org/jira/browse/CASSANDRASC-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-42: -- Labels: pull-request-available (was: ) > Introduce new handler for Keyspaces/ColumnFamily operations > --- > > Key: CASSANDRASC-42 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-42 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Keyspace information is required when doing bulk reads and writes from > Cassandra, including ColumnFamily (table) information. For example, column > type information can be used to determine a mapping to a different system > such as Spark. Checking whether a keyspace/column family exists before > starting an import operation is desired. -- 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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598053#comment-17598053 ] Ekaterina Dimitrova edited comment on CASSANDRA-17854 at 8/30/22 8:21 PM: -- Thanks [~mck] and [~brandon.williams] I was thinking initially to update those additional docker files when we update the Jenkins scripts but you were quick with the patch :) Thanks for that. I did a quick check and you add only JDK17 to the docker images but you don't touch the scripts that will do the builds and leave that to CASSANDRA-17869. Looks OK to me I will look to build the testing image and test all branches and CI... was (Author: e.dimitrova): Thanks [~mck] and [~brandon.williams] I was thinking initially to update those additional docker files when we update the Jenkins scripts but you were quick with the patch :) Thanks for that. I did a quick check and you add only JDK17 to the docker images but you don't touch the scripts that will do the builds and leave that to CASSANDRA-17869. I will look to build the testing image and test all branches and CI... > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598053#comment-17598053 ] Ekaterina Dimitrova commented on CASSANDRA-17854: - Thanks [~mck] and [~brandon.williams] I was thinking initially to update those when we update the Jenkins scripts but you were quick with the patch :) Thanks for that. I did a quick check and you add only JDK17 to the docker images but you don't touch the scripts that will do the builds and leave that to CASSANDRA-17869. I will look to build the testing image and test all branches and CI... > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598053#comment-17598053 ] Ekaterina Dimitrova edited comment on CASSANDRA-17854 at 8/30/22 8:20 PM: -- Thanks [~mck] and [~brandon.williams] I was thinking initially to update those additional docker files when we update the Jenkins scripts but you were quick with the patch :) Thanks for that. I did a quick check and you add only JDK17 to the docker images but you don't touch the scripts that will do the builds and leave that to CASSANDRA-17869. I will look to build the testing image and test all branches and CI... was (Author: e.dimitrova): Thanks [~mck] and [~brandon.williams] I was thinking initially to update those when we update the Jenkins scripts but you were quick with the patch :) Thanks for that. I did a quick check and you add only JDK17 to the docker images but you don't touch the scripts that will do the builds and leave that to CASSANDRA-17869. I will look to build the testing image and test all branches and CI... > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17768) streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase 1: Refactor Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-17768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17768: Fix Version/s: 4.1-rc (was: 4.1-beta) > streaming_keep_alive_period is not used after [CASSANDRA-16927] CEP-10 Phase > 1: Refactor Streaming > -- > > Key: CASSANDRA-17768 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17768 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Streaming and Messaging >Reporter: Ekaterina Dimitrova >Assignee: Aleksey Yeschenko >Priority: Normal > Fix For: 4.1-rc, 4.1.x, 4.x > > > While working on another ticket I noticed that after [CASSANDRA-16927] CEP-10 > Phase 1: Refactor Streaming > streaming_keep_alive_period is not used anymore, except to print it in error > message > [here|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/streaming/StreamSession.java#L689] > If the property should not be used anymore, we need to deprecate it and fix > the error message as it is misleading. > [~benedict] , [~samt] , [~aleksey] , can you, please, check and take care of > this one as authors of that patch? > Thank you in advance! -- 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-17854) Add JDK17 to our test docker images
[
https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598017#comment-17598017
]
Michael Semb Wever edited comment on CASSANDRA-17854 at 8/30/22 6:56 PM:
-
LGTM.
-Note, the {{cassandra-deb-packaging.sh}} change can break any builds currently
running.-
was (Author: michaelsembwever):
LGTM.
Note, the {{cassandra-deb-packaging.sh}} change can break any builds currently
running.
> Add JDK17 to our test docker images
> ---
>
> Key: CASSANDRA-17854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17854
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support JDK 17 I want to add JDK 17 to our test images to
> enable our CIs for testing with JDK 17
>
--
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-17854) Add JDK17 to our test docker images
[
https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598017#comment-17598017
]
Michael Semb Wever commented on CASSANDRA-17854:
LGTM.
Note, the {{cassandra-deb-packaging.sh}} change can break any builds currently
running.
> Add JDK17 to our test docker images
> ---
>
> Key: CASSANDRA-17854
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17854
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> In preparation to support JDK 17 I want to add JDK 17 to our test images to
> enable our CIs for testing with JDK 17
>
--
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-16860) Add --older-than option to nodetool clearsnapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16860:
--
Test and Documentation Plan:
java 11 precommit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1234/workflows/695a67c6-5ab6-411a-8a6b-82245b0d7ca0
java 8 precommit
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1234/workflows/ca06e0f1-9309-4e84-ac90-45743c799925
was:add tests
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra/pull/1828
> Add --older-than option to nodetool clearsnapshot
> -
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Snapshots, Tool/nodetool
>Reporter: Jack Casey
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CASSANDRA-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598013#comment-17598013 ] Brandon Williams edited comment on CASSANDRA-17854 at 8/30/22 6:46 PM: --- I have a [branch|https://github.com/driftx/cassandra-builds/tree/CASSANDRA-17854] that: * removes buster, centos8, and jessie * adds bullseye with j8, j11, j17 * adds j17 to almalinux and centos7 I didn't touch anything destined for CASSANDRA-17869 here, and note that j17 for centos7 will be in /opt/jdk-17 since it was manually installed. was (Author: brandon.williams): I have a [branch|https://github.com/driftx/cassandra-builds/tree/CASSANDRA-17854] that: * removes buster, centos8, and jessie * adds bullseye with j8, j11, j17 * add j17 to almalinux and centos7 I didn't touch anything destined for CASSANDRA-17869 here, and note that j17 for centos7 will be in /opt/jdk-17 since it was manually installed. > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598013#comment-17598013 ] Brandon Williams commented on CASSANDRA-17854: -- I have a [branch|https://github.com/driftx/cassandra-builds/tree/CASSANDRA-17854] that: * removes buster, centos8, and jessie * adds bullseye with j8, j11, j17 * add j17 to almalinux and centos7 I didn't touch anything destined for CASSANDRA-17869 here, and note that j17 for centos7 will be in /opt/jdk-17 since it was manually installed. > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17757) A user should not be able to manually remove ephemeral snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-17757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17757: -- Source Control Link: https://github.com/apache/cassandra/commit/1e2b60821327c158cba1c11d98eea68531178893 Resolution: Fixed Status: Resolved (was: Ready to Commit) java 11 precommit https://app.circleci.com/pipelines/github/instaclustr/cassandra/1232/workflows/0ee2b67a-28d3-496e-a372-da234292ec41 java 8 precommit https://app.circleci.com/pipelines/github/instaclustr/cassandra/1232/workflows/111cb22a-ae40-481f-8831-5d1af3c668bd > A user should not be able to manually remove ephemeral snapshots > > > Key: CASSANDRA-17757 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17757 > Project: Cassandra > Issue Type: New Feature > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.2 > > Time Spent: 40m > Remaining Estimate: 0h > > in CASSANDRA-16911 we introduced the "-e" flag to nodetool listsnaphots which > are returning ephemerals as well. An operator might try to remove these > snapshots by hand. This should not be possible as these snapshots are there > for repair to work on and manual removal breaks it. To be complete, these > snapshots are removed as part of repair mechanism automatically, or they are > removed on the next reboot upon node' start. They should never be removed by > a human. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (1b9c6d83ec -> 1e2b608213)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1b9c6d83ec Merge branch 'cassandra-4.1' into trunk add 1e2b608213 Prevent a user from manually removing ephemeral snapshots No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/db/Keyspace.java | 14 .../cassandra/service/SnapshotVerbHandler.java | 2 +- .../apache/cassandra/service/StorageService.java | 19 +- .../cassandra/service/snapshot/SnapshotLoader.java | 20 -- .../service/snapshot/SnapshotManager.java | 2 +- .../cassandra/service/snapshot/TableSnapshot.java | 16 + .../distributed/test/EphemeralSnapshotTest.java| 74 ++ .../apache/cassandra/db/SystemKeyspaceTest.java| 9 +-- .../service/snapshot/SnapshotLoaderTest.java | 34 ++ 10 files changed, 153 insertions(+), 38 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17851) Add interim prioritization logic for CompactionTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-17851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598010#comment-17598010
]
Brandon Williams commented on CASSANDRA-17851:
--
Ok, that is past the build phase so we're good to go, that must have been a
circle thing.
> Add interim prioritization logic for CompactionTasks
>
>
> Key: CASSANDRA-17851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17851
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While ultimately we could serve to have a real scheduler and single entry
> point for compactions, for now some moderate progress seems in order. There
> are cases where, during expansions, you can end up in a state where you can't
> finish upgrading sstables as they keep getting aborted by Incremental Repair
> and other operations that ultimately should be lower priority and not have
> the ability to cancel these operations.
> The idea here is that tasks like {{upgradestables}} and {{cleanup}} (and
> other tasks that have the same priority) will get serialised since
> {{markAllCompacting}} is synchronising on data, and higher priority tasks
> will be able to still cancel others via {{runWithCompactionsDisabled}}.
--
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-17851) Add interim prioritization logic for CompactionTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-17851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597989#comment-17597989
]
Brandon Williams edited comment on CASSANDRA-17851 at 8/30/22 5:25 PM:
---
If it's failing the build we can't commit this, all builds will fail afterward
and CI will be broken.
I started a jenkins run to doublecheck:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1905/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1905/pipeline]
was (Author: brandon.williams):
If it's failing the build we can't commit this, all builds will fail afterward
and CI will be broken.
> Add interim prioritization logic for CompactionTasks
>
>
> Key: CASSANDRA-17851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17851
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While ultimately we could serve to have a real scheduler and single entry
> point for compactions, for now some moderate progress seems in order. There
> are cases where, during expansions, you can end up in a state where you can't
> finish upgrading sstables as they keep getting aborted by Incremental Repair
> and other operations that ultimately should be lower priority and not have
> the ability to cancel these operations.
> The idea here is that tasks like {{upgradestables}} and {{cleanup}} (and
> other tasks that have the same priority) will get serialised since
> {{markAllCompacting}} is synchronising on data, and higher priority tasks
> will be able to still cancel others via {{runWithCompactionsDisabled}}.
--
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-17757) A user should not be able to manually remove ephemeral snapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-17757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597991#comment-17597991 ] Stefan Miklosovic commented on CASSANDRA-17757: --- I have also run 300x circle on added junit test https://app.circleci.com/pipelines/github/instaclustr/cassandra/1232/workflows/bda47ced-ff64-428e-9398-5c293d7c00d8/jobs/4994 > A user should not be able to manually remove ephemeral snapshots > > > Key: CASSANDRA-17757 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17757 > Project: Cassandra > Issue Type: New Feature > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.2 > > Time Spent: 40m > Remaining Estimate: 0h > > in CASSANDRA-16911 we introduced the "-e" flag to nodetool listsnaphots which > are returning ephemerals as well. An operator might try to remove these > snapshots by hand. This should not be possible as these snapshots are there > for repair to work on and manual removal breaks it. To be complete, these > snapshots are removed as part of repair mechanism automatically, or they are > removed on the next reboot upon node' start. They should never be removed by > a human. -- 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-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597990#comment-17597990
]
Stefan Miklosovic commented on CASSANDRA-17005:
---
I still see it in circle
https://app.circleci.com/pipelines/github/instaclustr/cassandra/1232/workflows/0ee2b67a-28d3-496e-a372-da234292ec41/jobs/5002/tests#failed-test-0
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/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 =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2: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 =
[jira] [Commented] (CASSANDRA-17851) Add interim prioritization logic for CompactionTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-17851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597989#comment-17597989
]
Brandon Williams commented on CASSANDRA-17851:
--
If it's failing the build we can't commit this, all builds will fail afterward
and CI will be broken.
> Add interim prioritization logic for CompactionTasks
>
>
> Key: CASSANDRA-17851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17851
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While ultimately we could serve to have a real scheduler and single entry
> point for compactions, for now some moderate progress seems in order. There
> are cases where, during expansions, you can end up in a state where you can't
> finish upgrading sstables as they keep getting aborted by Incremental Repair
> and other operations that ultimately should be lower priority and not have
> the ability to cancel these operations.
> The idea here is that tasks like {{upgradestables}} and {{cleanup}} (and
> other tasks that have the same priority) will get serialised since
> {{markAllCompacting}} is synchronising on data, and higher priority tasks
> will be able to still cancel others via {{runWithCompactionsDisabled}}.
--
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-17851) Add interim prioritization logic for CompactionTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-17851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597985#comment-17597985
]
Alex Petrov commented on CASSANDRA-17851:
-
+1. Build seems to be failing because of a suspected resource leak, but I've
checked the code and it seems to be safe to return there, since closeable
{{tasks}} is empty at that point.
> Add interim prioritization logic for CompactionTasks
>
>
> Key: CASSANDRA-17851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17851
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While ultimately we could serve to have a real scheduler and single entry
> point for compactions, for now some moderate progress seems in order. There
> are cases where, during expansions, you can end up in a state where you can't
> finish upgrading sstables as they keep getting aborted by Incremental Repair
> and other operations that ultimately should be lower priority and not have
> the ability to cancel these operations.
> The idea here is that tasks like {{upgradestables}} and {{cleanup}} (and
> other tasks that have the same priority) will get serialised since
> {{markAllCompacting}} is synchronising on data, and higher priority tasks
> will be able to still cancel others via {{runWithCompactionsDisabled}}.
--
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-17851) Add interim prioritization logic for CompactionTasks
[
https://issues.apache.org/jira/browse/CASSANDRA-17851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-17851:
Reviewers: Alex Petrov
Status: Review In Progress (was: Patch Available)
> Add interim prioritization logic for CompactionTasks
>
>
> Key: CASSANDRA-17851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17851
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While ultimately we could serve to have a real scheduler and single entry
> point for compactions, for now some moderate progress seems in order. There
> are cases where, during expansions, you can end up in a state where you can't
> finish upgrading sstables as they keep getting aborted by Incremental Repair
> and other operations that ultimately should be lower priority and not have
> the ability to cancel these operations.
> The idea here is that tasks like {{upgradestables}} and {{cleanup}} (and
> other tasks that have the same priority) will get serialised since
> {{markAllCompacting}} is synchronising on data, and higher priority tasks
> will be able to still cancel others via {{runWithCompactionsDisabled}}.
--
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-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597984#comment-17597984
]
Paulo Motta commented on CASSANDRA-17804:
-
Thanks for the test runs [~adelapena]. Would you mind committing this?
Unfortunately I'm not able to commit this before a few days.
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
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-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597983#comment-17597983
]
Andres de la Peña commented on CASSANDRA-17804:
---
It seems that all the runs above have succeeded :)
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (78ebff68d -> 601902293)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 78ebff68d generate docs for 538513bd new 601902293 generate docs for 538513bd This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (78ebff68d) \ N -- N -- N refs/heads/asf-staging (601902293) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597969#comment-17597969
]
Andres de la Peña commented on CASSANDRA-17804:
---
Here are some repeated runs of the fixed flaky test, still running:
||branch||vnodes||CI||
|4.1|false|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2023/workflows/942564a7-5d9f-4c12-b2f0-4ca5cc490749]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2023/workflows/978ca93d-b464-478c-a3df-6628f0f58545]|
|4.1|true|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2026/workflows/32cd730b-e299-4889-8835-770156956ac7]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2026/workflows/9702e9e6-fc1f-4981-8d83-4ce7d3ef65f2]|
|trunk|false|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2024/workflows/8e78ad06-c453-4bb4-ad32-4ebce1ddc2be]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2024/workflows/bdd5cf85-5766-4352-9a20-05b01feb0aa2]|
|trunk|true|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2024/workflows/8e78ad06-c453-4bb4-ad32-4ebce1ddc2be]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2025/workflows/f3ef33b3-37ee-44fb-b5c3-274dc24a338b]|
The CircleCI config file for these runs has been generated with:
{code:java}
.circleci/generate.sh -m \
-e REPEATED_UTEST_TARGET=test-jvm-dtest-some \
-e REPEATED_UTEST_COUNT=500 \
-e
REPEATED_UTEST_CLASS=org.apache.cassandra.distributed.test.AutoSnapshotTtlTest \
-e REPEATED_UTEST_METHODS=testAutoSnapshotTTlOnDropAfterRestart \
-e REPEATED_UTEST_VNODES=true
{code}
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17854: - Complexity: Normal (was: Low Hanging Fruit) > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-16413) Byteman fails to install injections after Jacoco upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-16413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597751#comment-17597751 ] Brandon Williams commented on CASSANDRA-16413: -- bq. Is there concerns/issues with jenkins codecoverage only running on trunk+JDK17 ? I'm not crazy about it, but it's been so long without it I don't think it will be terribly missed. > Byteman fails to install injections after Jacoco upgrade > > > Key: CASSANDRA-16413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16413 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > This ticket is a follow up on CASSANDRA-16365 and it should be worked on > after the Jacoco upgrade is committed > List of the failing tests: > org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.testCompressedCommitLogBackpressure > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testSSTableNotEnoughDiskSpaceForCompactionGetsDropped > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testRuntimeExceptionWhenNoDiskSpaceForCompaction > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopUserDefinedCompactionRepaired > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopSubRangeCompactionRepaired > org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction > org.apache.cassandra.gms.PendingRangeCalculatorServiceTest.testDelayedResponse > org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure > -- 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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597747#comment-17597747 ] Brandon Williams commented on CASSANDRA-17854: -- I think we should remove centos8 and jessie, just being there causes me some cognitive overhead every time I do something there. centos7 at least will require a manual installation, I'll look into a patch there. > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
Michael Semb Wever created CASSANDRA-17869:
--
Summary: Add JDK17 option to cassandra-builds (build-scripts and
jenkins dsl) and on jenkins agents
Key: CASSANDRA-17869
URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
Project: Cassandra
Issue Type: Task
Components: Build
Reporter: Michael Semb Wever
Add JDK17 option to cassandra-builds build-scripts, they only currently support
options {{8}} and {{1}}.
Add JDK17 to the matrix axes in the jenkins dsl.
Ensure JDK17 is installed on all the jenkins agents.
--
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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597599#comment-17597599 ] Michael Semb Wever commented on CASSANDRA-17854: Changes to docker/testing/ubuntu2004_j11.docker look good. But the artifacts (and release building) needs JDK17 in these images too: - docker/almalinux-image.docker - docker/buster-image.docker - docker/centos7-image.docker - docker/centos8-image.docker - docker/jessie-image.docker (jessie and centos8 are no longer used anywhere, and could instead just be removed.) > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17854: --- Reviewers: Michael Semb Wever > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- 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-16413) Byteman fails to install injections after Jacoco upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-16413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597595#comment-17597595 ] Michael Semb Wever commented on CASSANDRA-16413: I'm happy with this only landing in trunk. (We've lived with 4.0 as-is so far already.) Agree with JDK17 jenkins trunk enabled. Is there concerns/issues with jenkins codecoverage only running on trunk+JDK17 ? > Byteman fails to install injections after Jacoco upgrade > > > Key: CASSANDRA-16413 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16413 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > This ticket is a follow up on CASSANDRA-16365 and it should be worked on > after the Jacoco upgrade is committed > List of the failing tests: > org.apache.cassandra.db.commitlog.CommitLogSegmentBackpressureTest.testCompressedCommitLogBackpressure > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testSSTableNotEnoughDiskSpaceForCompactionGetsDropped > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testRuntimeExceptionWhenNoDiskSpaceForCompaction > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopUserDefinedCompactionRepaired > org.apache.cassandra.db.compaction.CompactionsBytemanTest.testStopSubRangeCompactionRepaired > org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction > org.apache.cassandra.gms.PendingRangeCalculatorServiceTest.testDelayedResponse > org.apache.cassandra.hints.HintsBufferPoolTest.testBackpressure > -- 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
