[jira] [Comment Edited] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709226#comment-17709226
]
Claude Warren edited comment on CASSANDRA-12937 at 4/6/23 6:53 AM:
---
Looking at CompressionParams there are a number of default configurations e.g.
snappy(), lz4(), and noCompression() that I thought would be in common use.
What I wanted to do was to provide an easy way to get to call those methods as
well as provide the ability to load any compressor via the map.
Also, early on the idea of putting chunk_length_in_kb was rejected with the
"16KiB" form for the input requested.
If it is agreed to remove the shortcuts and use the simple map form with the
parameters I'll make those changes.
I did come across a note that says that configuration file and CQL use
different parameters for compression, thus I onluy implemented
min_compress_ratio and used it to calculate max_compression_length.
So I got to where the code is by trying to support the defaults in
CompressonParams and following the min_compress_ratio not
max_compression_length in the config files.
you can configure the ztsd with 12Kib chunks by setting:
{code:java}
sstable_compressor:
chunk_length: 12KiB
type: zstd
{code}
was (Author: claudenw):
Looking at CompressionParams there are a number of default configurations e.g.
snappy(), lz4(), and noCompression() that I thought would be in common use.
What I wanted to do was to provide an easy way to get to call those methods as
well as provide the ability to load any compressor via the map.
Also, early on the idea of putting chunk_length_in_kb was rejected with the
"16KiB" form for the input requested.
If it is agreed to remove the shortcuts and use the simple map form with the
parameters I'll make those changes.
I did come across a note that says that configuration file and CQL use
different parameters for compression, thus I onluy implemented
min_compress_ratio and used it to calculate max_compression_length.
So I got to where the code is by trying to support the defaults in
CompressonParams and following the min_compress_ratio not
max_compression_length in the config files.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709227#comment-17709227
]
Jacek Lewandowski edited comment on CASSANDRA-18399 at 4/6/23 6:50 AM:
---
Thanks for trying [~e.dimitrova]
Answering your questions:
1) because such commits may have different titles, also because sometimes
changes to circle ci config can be part of some other commit - this approach
simply handles all the cases. Also, this is a script generator so you can
comment out / remove that line from the output
2) if you mean, git push --atomic -n, then it is added, and in new version it
does the verification whether:
- the newer branch contains all the commits from the previous branch + one new
merge commit with correct versions
- the first branch contains only one commit, which is not a merge commit
Additionally, the script generates git diff --name-only, and git show commands
for each branch reported by git push -n
3) this is a good idea, but I'd rather do ant artifacts; though - I don't know
where to get the supported java versions from, also, I don't know what is the
common way to switch the java version
EDIT: I can see a property java.supported got added in 5.0, so we can use that,
and hardcode for previous versions. We can assume JAVA__HOME env
properties to be present so that the script can consistently switch
4) because this must be branch/version agnostic stuff
The error you reported is valid if your commit does not cherry-pick cleanly -
was that the case?
was (Author: jlewandowski):
Thanks for trying [~e.dimitrova]
Answering your questions:
1) because such commits may have different titles, also because sometimes
changes to circle ci config can be part of some other commit - this approach
simply handles all the cases. Also, this is a script generator so you can
comment out / remove that line from the output
2) if you mean, git push --atomic -n, then it is added, and in new version it
does the verification whether:
- the newer branch contains all the commits from the previous branch + one new
merge commit with correct versions
- the first branch contains only one commit, which is not a merge commit
Additionally, the script generates git diff --name-only, and git show commands
for each branch reported by git push -n
3) this is a good idea, but I'd rather do ant artifacts; though - I don't know
where to get the supported java versions from, also, I don't know what is the
common way to switch the java version
4) because this must be branch/version agnostic stuff
The error you reported is valid if your commit does not cherry-pick cleanly -
was that the case?
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> gi
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709227#comment-17709227
]
Jacek Lewandowski commented on CASSANDRA-18399:
---
Thanks for trying [~e.dimitrova]
Answering your questions:
1) because such commits may have different titles, also because sometimes
changes to circle ci config can be part of some other commit - this approach
simply handles all the cases. Also, this is a script generator so you can
comment out / remove that line from the output
2) if you mean, git push --atomic -n, then it is added, and in new version it
does the verification whether:
- the newer branch contains all the commits from the previous branch + one new
merge commit with correct versions
- the first branch contains only one commit, which is not a merge commit
Additionally, the script generates git diff --name-only, and git show commands
for each branch reported by git push -n
3) this is a good idea, but I'd rather do ant artifacts; though - I don't know
where to get the supported java versions from, also, I don't know what is the
common way to switch the java version
4) because this must be branch/version agnostic stuff
The error you reported is valid if your commit does not cherry-pick cleanly -
was that the case?
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
>
> git switch cassandra-4.0
> git reset --hard origin/cassandra-4.0
> git merge -s ours --log --no-edit cassandra-3.11
> git cherry-pick -n 2227c5c7af && git commit -a --amend --no-edit # 2227c5c7af
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n a71d4e
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709226#comment-17709226
]
Claude Warren commented on CASSANDRA-12937:
---
Looking at CompressionParams there are a number of default configurations e.g.
snappy(), lz4(), and noCompression() that I thought would be in common use.
What I wanted to do was to provide an easy way to get to call those methods as
well as provide the ability to load any compressor via the map.
Also, early on the idea of putting chunk_length_in_kb was rejected with the
"16KiB" form for the input requested.
If it is agreed to remove the shortcuts and use the simple map form with the
parameters I'll make those changes.
I did come across a note that says that configuration file and CQL use
different parameters for compression, thus I onluy implemented
min_compress_ratio and used it to calculate max_compression_length.
So I got to where the code is by trying to support the defaults in
CompressonParams and following the min_compress_ratio not
max_compression_length in the config files.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-18430) When decommissioning should set Severity to limit traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18430: - Reviewers: Brandon Williams > When decommissioning should set Severity to limit traffic > - > > Key: CASSANDRA-18430 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18430 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > > When we are decommissioning we first set LEAVING, then LEFT, then disable > networking; timeouts start to follow at this last stage. LEFT nodes should > not be seen as part of the ring, but that may not be seen before the network > is disabled. To better mitigate timeouts we should set severity as part of > decom during the LEAVING phase; by setting severity reads should deprioritize > traffic to this node. > Remote DC writes do not leverage proximity or severity and instead use random > for its select, writes may still timeout even though we know the node is > leaving, and severity is set… to work in this model we should update remote > DC writes to deprioritize nodes with severity set -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709147#comment-17709147
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
Problem fixed in CASSANDRA-18431. JDK17 CI runs should be back to what they
were last week.
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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] [Updated] (CASSANDRA-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18431:
Since Version: (was: 5.0)
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18431:
Fix Version/s: 5.0
(was: 5.x)
Since Version: 5.0
Source Control Link:
https://github.com/apache/cassandra/commit/d1d733bee5ba85088a77d5c1430705dbb47ab68c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709146#comment-17709146
]
Ekaterina Dimitrova commented on CASSANDRA-18431:
-
Committed:
To https://github.com/apache/cassandra
[58f5301e78..d1d733bee5|https://github.com/apache/cassandra/commit/d1d733bee5ba85088a77d5c1430705dbb47ab68c]
trunk -> trunk
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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: Fix JDK17 startup issue after CASSANDRA-17199; temporary workaround, to be reverted after CASSANDRA-18239 Patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new d1d733bee5 Fix JDK17 startup issue after CASSANDRA-17199; temporary workaround, to be reverted after CASSANDRA-18239 Patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever for CASSANDRA-18431 d1d733bee5 is described below commit d1d733bee5ba85088a77d5c1430705dbb47ab68c Author: Ekaterina Dimitrova AuthorDate: Wed Apr 5 16:29:28 2023 -0400 Fix JDK17 startup issue after CASSANDRA-17199; temporary workaround, to be reverted after CASSANDRA-18239 Patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever for CASSANDRA-18431 --- build.xml | 1 + conf/jvm17-server.options | 2 ++ 2 files changed, 3 insertions(+) diff --git a/build.xml b/build.xml index f75314e044..625b234a8f 100644 --- a/build.xml +++ b/build.xml @@ -257,6 +257,7 @@ --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.math=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED +--add-opens java.base/java.net=ALL-UNNAMED diff --git a/conf/jvm17-server.options b/conf/jvm17-server.options index 3e8d2cef76..98a70a20f9 100644 --- a/conf/jvm17-server.options +++ b/conf/jvm17-server.options @@ -103,6 +103,8 @@ --add-opens java.base/java.math=ALL-UNNAMED #in-jvm tests? plus # https://chronicle.software/chronicle-support-java-17/ --add-opens java.base/java.lang.reflect=ALL-UNNAMED +#jamm post CASSANDRA-17199 +--add-opens java.base/java.net=ALL-UNNAMED ### GC logging options -- uncomment to enable - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18431:
Reviewers: Michael Semb Wever, Ekaterina Dimitrova
Michael Semb Wever, Ekaterina Dimitrova (was: Ekaterina
Dimitrova, Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18431:
Status: Ready to Commit (was: Review In Progress)
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709123#comment-17709123
]
Michael Semb Wever commented on CASSANDRA-18431:
+1
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18423) Test failure: org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
[
https://issues.apache.org/jira/browse/CASSANDRA-18423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709113#comment-17709113
]
Brandon Williams commented on CASSANDRA-18423:
--
I noticed this test only started to appear (and fail) after CASSANDRA-18262,
perhaps due to running checkstyle for both j8 and j11? I reverted it and ran a
build [here|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2410/]
where the test did not fail.
> Test failure:
> org.apache.cassandra.io.sstable.indexsummary.IndexSummaryTest.testLargeIndexSummary
> -
>
> Key: CASSANDRA-18423
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18423
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.x
>
>
> Failed 6 times in the last 6 runs. Flakiness: 0%, Stability: 0%
> {noformat}
> unit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please
> note the time in the report does not reflect the time until the VM exit.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1394)
> {noformat}
> Note that only the 'default' version of this test is failing:
> https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.io.sstable.indexsummary/IndexSummaryTest/testLargeIndexSummary
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709106#comment-17709106
]
Ekaterina Dimitrova edited comment on CASSANDRA-18431 at 4/5/23 8:52 PM:
-
[Patch|https://github.com/ekaterinadimitrova2/cassandra/commit/77b2a7a7d230a404339e1d7413e01d3664b8a9c3],
[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
[~dcapwell], [~mck] - I believe this brought us to the CI run seen
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
before CASSANDRA-17199
We can revert when jamm gets upgraded in CASSANDRA-18329
Can I get a review, please?
was (Author: e.dimitrova):
[Patch|https://github.com/ekaterinadimitrova2/cassandra/commit/77b2a7a7d230a404339e1d7413e01d3664b8a9c3],
[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
[~dcapwell], [~mck] - I believe this brought us to the CI run seen
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
before CASSANDRA-17199
We can revert when jamm gets upgraded in CASSANDRA-18329
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709106#comment-17709106
]
Ekaterina Dimitrova commented on CASSANDRA-18431:
-
[Patch|https://github.com/ekaterinadimitrova2/cassandra/commit/77b2a7a7d230a404339e1d7413e01d3664b8a9c3],
[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
[~dcapwell], [~mck] - I believe this brought us to the CI run seen
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
before CASSANDRA-17199
We can revert when jamm gets upgraded in CASSANDRA-18329
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18431:
Test and Documentation Plan:
[Patch|https://github.com/ekaterinadimitrova2/cassandra/commit/77b2a7a7d230a404339e1d7413e01d3664b8a9c3],
[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2322/workflows/20db9d1b-90ee-44dc-9cd5-6360b5f9671d]
Status: Patch Available (was: In Progress)
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709098#comment-17709098 ] Ekaterina Dimitrova edited comment on CASSANDRA-18262 at 4/5/23 8:20 PM: - bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see this statement anywhere, I see: bq. one reason could be that people are developing locally against Java 11 already. when they shouldn't be developing against other versions ;-) In my opinion, instead of adding checks to accommodate that development we should tell people they should switch to JDK whatever version we are on now and this will speed the review process too. Please feel free to raise this to the mailing list was (Author: e.dimitrova): bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see this statement anywhere, I see: bq. one reason could be that people are developing locally against Java 11 already. when they shouldn't be developing against other versions ;-) > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709098#comment-17709098 ] Ekaterina Dimitrova commented on CASSANDRA-18262: - bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see this statement anywhere, I see: bq. one reason could be that people are developing locally against Java 11 already. when they shouldn't be developing against other versions ;-) > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262 ] Ekaterina Dimitrova deleted comment on CASSANDRA-18262: - was (Author: e.dimitrova): bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see anyone here saying that... (skipping tests...) > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709092#comment-17709092 ] Ekaterina Dimitrova edited comment on CASSANDRA-18262 at 4/5/23 8:07 PM: - bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see anyone here saying that... (skipping tests...) was (Author: e.dimitrova): bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see anyone here saying that... > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709092#comment-17709092 ] Ekaterina Dimitrova commented on CASSANDRA-18262: - bq. "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". I do not see anyone here saying that... > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18431) Cassandra doesn't start on JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18431:
Description:
CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
internals and prevents us from starting Cassandra with JDK17. This will be
solved with CASSANDRA-18329.
Until new version of jamm lands we can workaround the problem either by adding
add-opens or by replacing temporarily
{code:java}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));
{code}
with
{code:java}
public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
{code}
measured with JOL.
Then we can switch back to the current call
[here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
later.
was:
CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
internals and prevents us from starting Cassandra with JDK17. This will be
solved with CASSANDRA-18329.
Until new version of jamm lands we can workaround the problem either by adding
add-opens or by replacing temporarily
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));
with
public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
taken from JOL.
Then we can switch back to the current call
[here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
later.
> Cassandra doesn't start on JDK17
>
>
> Key: CASSANDRA-18431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18431
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK
> internals and prevents us from starting Cassandra with JDK17. This will be
> solved with CASSANDRA-18329.
> Until new version of jamm lands we can workaround the problem either by
> adding add-opens or by replacing temporarily
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE =
> ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42));
> {code}
> with
> {code:java}
> public static final long IPV6_SOCKET_ADDRESS_SIZE = 168;
> {code}
> measured with JOL.
> Then we can switch back to the current call
> [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45]
> later.
--
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-18431) Cassandra doesn't start on JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18431: Epic Link: CASSANDRA-16895 > Cassandra doesn't start on JDK17 > > > Key: CASSANDRA-18431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18431 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK > internals and prevents us from starting Cassandra with JDK17. This will be > solved with CASSANDRA-18329. > Until new version of jamm lands we can workaround the problem either by > adding add-opens or by replacing temporarily > public static final long IPV6_SOCKET_ADDRESS_SIZE = > ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42)); > with > public static final long IPV6_SOCKET_ADDRESS_SIZE = 168; > taken from JOL. > Then we can switch back to the current call > [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45] > later. -- 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-18431) Cassandra doesn't start on JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18431: Fix Version/s: 5.x > Cassandra doesn't start on JDK17 > > > Key: CASSANDRA-18431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18431 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK > internals and prevents us from starting Cassandra with JDK17. This will be > solved with CASSANDRA-18329. > Until new version of jamm lands we can workaround the problem either by > adding add-opens or by replacing temporarily > public static final long IPV6_SOCKET_ADDRESS_SIZE = > ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42)); > with > public static final long IPV6_SOCKET_ADDRESS_SIZE = 168; > taken from JOL. > Then we can switch back to the current call > [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45] > later. -- 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-18431) Cassandra doesn't start on JDK17
Ekaterina Dimitrova created CASSANDRA-18431: --- Summary: Cassandra doesn't start on JDK17 Key: CASSANDRA-18431 URL: https://issues.apache.org/jira/browse/CASSANDRA-18431 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK internals and prevents us from starting Cassandra with JDK17. This will be solved with CASSANDRA-18329. Until new version of jamm lands we can workaround the problem either by adding add-opens or by replacing temporarily public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42)); with public static final long IPV6_SOCKET_ADDRESS_SIZE = 168; taken from JOL. Then we can switch back to the current call [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45] later. -- 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-18431) Cassandra doesn't start on JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18431: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Build Discovered By: User Report Severity: Low Assignee: Ekaterina Dimitrova Status: Open (was: Triage Needed) > Cassandra doesn't start on JDK17 > > > Key: CASSANDRA-18431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18431 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > CASSANDRA-17199 added a new call to jamm measureDeep which hits some JDK > internals and prevents us from starting Cassandra with JDK17. This will be > solved with CASSANDRA-18329. > Until new version of jamm lands we can workaround the problem either by > adding add-opens or by replacing temporarily > public static final long IPV6_SOCKET_ADDRESS_SIZE = > ObjectSizes.measureDeep(new InetSocketAddress(getIpvAddress(16), 42)); > with > public static final long IPV6_SOCKET_ADDRESS_SIZE = 168; > taken from JOL. > Then we can switch back to the current call > [here|https://github.com/apache/cassandra/commit/721b6de555352bf0ac3ef7e36f94dc832f41#diff-1122d7d3efe9721af7244d373e66378f7e90cb05fd65859a52e8a3ea58a7c8f9R45] > later. -- 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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709083#comment-17709083
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 4/5/23 7:39 PM:
---
I did it here https://github.com/apache/cassandra/pull//files
The configuration is as simple as this:
{code}
sstable_compressor:
class: "org.apache.cassandra.io.compress.LZ4Compressor"
chunk_length_in_kb: "16"
min_compress_ratio: "0"
{code}
Since sstable_compressor is a map, it may contain whatever parameters. The
creation of compressor / validation is done upon node's startup.
This solution is prepared for whatever compressor, whatever parameters and it
accepts same parameters as specified in CQL so there is nothing new to learn.
was (Author: smiklosovic):
I did it here https://github.com/apache/cassandra/pull//files
The configuration is as simple as this:
{code}
sstable_compressor:
class: "org.apache.cassandra.io.compress.LZ4Compressor"
chunk_length_in_kb: "16"
min_compress_ratio: "0"
{code}
Since sstable_compressor is a map, it may contain whatever parameters. The
creation of compressor / validation is done upon node's startup.
This solution is prepared for whatever compressor, whatever parameters and it
accepts same parameters as specified in CQL so there nothing new to learn.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709083#comment-17709083
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
I did it here https://github.com/apache/cassandra/pull//files
The configuration is as simple as this:
{code}
sstable_compressor:
class: "org.apache.cassandra.io.compress.LZ4Compressor"
chunk_length_in_kb: "16"
min_compress_ratio: "0"
{code}
Since sstable_compressor is a map, it may contain whatever parameters. The
creation of compressor / validation is done upon node's startup.
This solution is prepared for whatever compressor, whatever parameters and it
accepts same parameters as specified in CQL so there nothing new to learn.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708947#comment-17708947
]
Ekaterina Dimitrova edited comment on CASSANDRA-17869 at 4/5/23 7:34 PM:
-
I figured that the JDK17 build doesn't start at the moment because of this (as
expected we do not have too much storage locally and in CI available so we
trigger the below warning), the main issue is initializing the partitioner and
jamm hitting JDK internals:
{code:java}
WARN [main] 2023-04-05 10:46:25,361 DatabaseDescriptor.java:675 - Only
44.801GiB free across all data volumes. Consider adding more capacity to your
cluster or removing obsolete snapshots
Exception (java.lang.ExceptionInInitializerError) encountered during startup:
null
java.lang.ExceptionInInitializerError
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
at org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:221)
at org.apache.cassandra.utils.ObjectSizes.(ObjectSizes.java:45)
... 15 more
ERROR [main] 2023-04-05 10:46:26,007 CassandraDaemon.java:910 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.
[jira] [Comment Edited] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709081#comment-17709081
]
Ekaterina Dimitrova edited comment on CASSANDRA-17869 at 4/5/23 7:31 PM:
-
{quote}Oh, I see that looks to be caused by
{code:java}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));{code}
{quote}
Yes, that is the problem. measureDeep is crawling the JDK internals and hits
something. That kind of issues are that [~b.le...@gmail.com] is working around
during his jamm maintenance. When we get the new version of jamm things will be
ok. Until then I can do probably just add-opens. If it doesn't start eagerly to
ask me for more and more and it is a matter of adding just 1-2 in order to get
through it I will go for that. If not we can go with your suggestion until the
new jamm release is in and it fixes this type of issues.
I will open another ticket now to fix it. Thanks for looking into that!
was (Author: e.dimitrova):
{quote}Oh, I see that looks to be caused by
{code:java}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));{code}
{quote}
Yes, that is the problem. measureDeep is crawling the JDK internals and hits
something. That kind of issues are that [~b.le...@gmail.com] is working around
during his jamm maintenance. When we get the new version things will be ok.
Until then I can do probably just add-opens. If it doesn't start eagerly to ask
me for more and more and it is a matter of adding just 1-2 in order to get
through it I will go for that. If not we can go with your suggestion until the
new jamm release is in and it fixes this type of issues.
I will open another ticket now to fix it. Thanks for looking into that!
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709081#comment-17709081
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
{quote}Oh, I see that looks to be caused by
{code:java}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));{code}
{quote}
Yes, that is the problem. measureDeep is crawling the JDK internals and hits
something. That kind of issues are that [~b.le...@gmail.com] is working around
during his jamm maintenance. When we get the new version things will be ok.
Until then I can do probably just add-opens. If it doesn't start eagerly to ask
me for more and more and it is a matter of adding just 1-2 in order to get
through it I will go for that. If not we can go with your suggestion until the
new jamm release is in and it fixes this type of issues.
I will open another ticket now to fix it. Thanks for looking into that!
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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] [Created] (CASSANDRA-18430) When decommissioning should set Severity to limit traffic
David Capwell created CASSANDRA-18430: - Summary: When decommissioning should set Severity to limit traffic Key: CASSANDRA-18430 URL: https://issues.apache.org/jira/browse/CASSANDRA-18430 Project: Cassandra Issue Type: Improvement Components: Legacy/Coordination Reporter: David Capwell When we are decommissioning we first set LEAVING, then LEFT, then disable networking; timeouts start to follow at this last stage. LEFT nodes should not be seen as part of the ring, but that may not be seen before the network is disabled. To better mitigate timeouts we should set severity as part of decom during the LEAVING phase; by setting severity reads should deprioritize traffic to this node. Remote DC writes do not leverage proximity or severity and instead use random for its select, writes may still timeout even though we know the node is leaving, and severity is set… to work in this model we should update remote DC writes to deprioritize nodes with severity set -- 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-18430) When decommissioning should set Severity to limit traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18430: -- Change Category: Performance Complexity: Normal Fix Version/s: 5.x Status: Open (was: Triage Needed) > When decommissioning should set Severity to limit traffic > - > > Key: CASSANDRA-18430 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18430 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > > When we are decommissioning we first set LEAVING, then LEFT, then disable > networking; timeouts start to follow at this last stage. LEFT nodes should > not be seen as part of the ring, but that may not be seen before the network > is disabled. To better mitigate timeouts we should set severity as part of > decom during the LEAVING phase; by setting severity reads should deprioritize > traffic to this node. > Remote DC writes do not leverage proximity or severity and instead use random > for its select, writes may still timeout even though we know the node is > leaving, and severity is set… to work in this model we should update remote > DC writes to deprioritize nodes with severity set -- 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-18430) When decommissioning should set Severity to limit traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-18430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-18430: - Assignee: David Capwell > When decommissioning should set Severity to limit traffic > - > > Key: CASSANDRA-18430 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18430 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > When we are decommissioning we first set LEAVING, then LEFT, then disable > networking; timeouts start to follow at this last stage. LEFT nodes should > not be seen as part of the ring, but that may not be seen before the network > is disabled. To better mitigate timeouts we should set severity as part of > decom during the LEAVING phase; by setting severity reads should deprioritize > traffic to this node. > Remote DC writes do not leverage proximity or severity and instead use random > for its select, writes may still timeout even though we know the node is > leaving, and severity is set… to work in this model we should update remote > DC writes to deprioritize nodes with severity set -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709058#comment-17709058
]
David Capwell edited comment on CASSANDRA-17869 at 4/5/23 6:36 PM:
---
{code}
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
{code}
Oh, I see that looks to be caused by
{code}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));
{code}
In some code paths we use hard coded values from JOL, so if this is an issue I
am 100% making this a constant based off JOL as well... The intent is for
memory tracking, so if we are off we store more or less streams than the ideal
state... so if we are good-enough it's fine.
On JDK8 I get 168, so 100% cool with replacing the RHS with "168"
was (Author: dcapwell):
{code}
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
{code}
Oh, I see that looks to be caused by
{code}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));
{code}
In some code paths we use hard coded values from JOL, so if this is an issue I
am 100% making this a constant based off JOL as well... The intent is for
memory tracking, so if we are off we store more or less streams than the ideal
state... so if we are good-enough its fine.
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709058#comment-17709058
]
David Capwell commented on CASSANDRA-17869:
---
{code}
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
{code}
Oh, I see that looks to be caused by
{code}
public static final long IPV6_SOCKET_ADDRESS_SIZE = ObjectSizes.measureDeep(new
InetSocketAddress(getIpvAddress(16), 42));
{code}
In some code paths we use hard coded values from JOL, so if this is an issue I
am 100% making this a constant based off JOL as well... The intent is for
memory tracking, so if we are off we store more or less streams than the ideal
state... so if we are good-enough its fine.
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709057#comment-17709057
]
David Capwell commented on CASSANDRA-17869:
---
[~e.dimitrova] I am not sure the relationship to CASSANDRA-17199. Your message
shows that we failed to create DD and that we get a log saying we are out of
disk space... The patch you linked (CASSANDRA-17199) adds logs to streaming to
know why a sub-stream failed; not sure the relationship to this work?
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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] [Comment Edited] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708899#comment-17708899
]
Michael Semb Wever edited comment on CASSANDRA-17869 at 4/5/23 6:13 PM:
CI
- artifacts: http://13.50.248.249:8080/job/Cassandra-trunk-artifacts/21/
- cqlsh-tests:
http://13.50.248.249:8080/job/Cassandra-trunk-cqlsh-tests/10/cython=yes,jdk=jdk_17_latest,label=cassandra/console
- unit: http://13.50.248.249:8080/job/Cassandra-trunk-test/4/
- jvm-dtest: http://13.50.248.249:8080/job/Cassandra-trunk-jvm-dtest/4/
- jvm-dtest-upgrade:
http://13.50.248.249:8080/job/Cassandra-trunk-jvm-dtest-upgrade/2/
- dtest: http://13.50.248.249:8080/job/Cassandra-trunk-dtest/10/
- dtest-upgrade: http://13.50.248.249:8080/job/Cassandra-trunk-dtest-upgrade/1/
Failures are similar to CircleCI:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2Ftrunk
was (Author: michaelsembwever):
CI
- artifacts: http://13.50.248.249:8080/job/Cassandra-trunk-artifacts/21/
- cqlsh-tests: …wip…
- unit: http://13.50.248.249:8080/job/Cassandra-trunk-test/4/
- jvm-dtest: http://13.50.248.249:8080/job/Cassandra-trunk-jvm-dtest/4/
- jvm-dtest-upgrade:
http://13.50.248.249:8080/job/Cassandra-trunk-jvm-dtest-upgrade/2/
- dtest: http://13.50.248.249:8080/job/Cassandra-trunk-dtest/10/
- dtest-upgrade: http://13.50.248.249:8080/job/Cassandra-trunk-dtest-upgrade/1/
Failures are similar to CircleCI:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2Ftrunk
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709048#comment-17709048
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
[~claude]
I have one question though ... as I look into it, currently, the configuration
is done like this, imagine I want to configure Zstd compression, so I would do:
{code}
sstable_compressor:
# defaults to true
enable: true
# defaults to 16KiB
chunk_length: 16KiB
# min_compress_ratio is only used in snappy, lz4, and custom implementations.
# defaults to 0.0 see CompressionParams.DEFAULT_MIN_COMPRESS_RATIO
#min_compress_ratio: 0.0
# type should be one of the `CompressorType` values: none, noop, lz4, snappy,
deflate, zstd or custom
type: zstd
# if custom type is specified compressor class and parameters must be provided
#compressor:
#- class_name: org.apache.cassandra.io.compress.LZ4Compressor # the
compressor class
# parameters:
#- param1 : value
{code}
However, by doing so, I can not use the same parameters as used upon CREATE
TABLE ... For example, I can not specify "compression_level". Where would I put
it.
Similarly, we basically lost a way how to use already existing options.
Currently, we would call this below, but where are other options?
{code}
case zstd:
return CompressionParams.zstd(chunk_length_in_kb);
{code}
It is good that there is general "compressor" field, but why not to simply call
"CompressionParams.fromMap(Map)" instead of
"SSTableCompressionOptions.getCompressionParams()"? So whole configuration
would be basically a map of parameters, same as we use it upon CQL creation.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: Review In Progress (was: Needs Committer)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709025#comment-17709025
]
Stefan Miklosovic edited comment on CASSANDRA-12937 at 4/5/23 5:25 PM:
---
also clean j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2055/workflows/3ec6e5cf-36bf-45aa-a794-27a88a1ee0de]
[~mck] would you take a look? on this branch, please?
[https://github.com/apache/cassandra/pull/]
was (Author: smiklosovic):
also clean j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2055/workflows/3ec6e5cf-36bf-45aa-a794-27a88a1ee0de]
[~mck] would you take a look? on this branch, please?
[https://github.com/instaclustr/cassandra/commits/CASSANDRA-12937]
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-12937:
--
Status: Needs Committer (was: Review In Progress)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709025#comment-17709025
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
also clean j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2055/workflows/3ec6e5cf-36bf-45aa-a794-27a88a1ee0de]
[~mck] would you take a look? on this branch, please?
[https://github.com/instaclustr/cassandra/commits/CASSANDRA-12937]
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709019#comment-17709019
]
Ekaterina Dimitrova edited comment on CASSANDRA-18399 at 4/5/23 5:16 PM:
-
I can run it on a Mac.
Just a few initial thoughts while reading it here:
1) Why do you cherry-pick at all CircleCI changes which are throwaway commit?
2) I am wondering, do we want maybe to add a dry-run -n option for the script?
Potentially with git diff or so to encourage people to verify changes pre -
commit? (Now this will be probably an option for committers only though)
3) Probably we can add also
{code:java}
ant realclean && ant jar build-test{code}
after applying a patch to a branch as per our [commit
process|https://cassandra.apache.org/_/development/how_to_commit.html]?
4) Why is this in cassandra-builds? I know we try to move to in-tree as much as
possible, though I understand that it can drift in time between branches. But I
wouldn't expect that to be an issue as since the 3 years and a half I am
working on Cassandra we didn't change anything in the merge strategy even once.
---
Started running the 3.0 script and got an error:
{code:java}
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(dc550dfdc7870b5f176487467e588f320d5b8c8e)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(c0bf31779b9c30765bb06191788953ccce46b9cb)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(eaa9ad32af1b460dec1a02c7184798b42ce0aecd)
error: your index file is unmerged.
fatal: cherry-pick failed
{code}
was (Author: e.dimitrova):
I can run it on a Mac.
Just a few initial thoughts while reading it here:
1) Why do you cherry-pick at all CircleCI changes which are throwaway commit?
2) I am wondering, do we want maybe to add a dry-run -n option for the script?
Potentially with git diff or so to encourage people to verify changes pre -
commit? (Now this will be probably an option for committers only though)
3) Probably we can add also
{code:java}
ant realclean && ant jar build-test{code}
after applying a patch to a branch as per our [commit
process|https://cassandra.apache.org/_/development/how_to_commit.html]?
4) Why is this in cassandra-builds? I know we try to move to in-tree as much as
possible, though I understand that the it can drift in time between branches.
But I wouldn't expect that to be an issue as since the 3 years and a half I am
working on Cassandra we didn't change anything in the merge strategy even once.
---
Started running the 3.0 script and got an error:
{code:java}
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(dc550dfdc7870b5f176487467e588f320d5b8c8e)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(c0bf31779b9c30765bb06191788953ccce46b9cb)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(eaa9ad32af1b460dec1a02c7184798b42ce0aecd)
error: your index file is unmerged.
fatal: cherry-pick failed
{code}
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circlec
[jira] [Comment Edited] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709019#comment-17709019
]
Ekaterina Dimitrova edited comment on CASSANDRA-18399 at 4/5/23 5:15 PM:
-
I can run it on a Mac.
Just a few initial thoughts while reading it here:
1) Why do you cherry-pick at all CircleCI changes which are throwaway commit?
2) I am wondering, do we want maybe to add a dry-run -n option for the script?
Potentially with git diff or so to encourage people to verify changes pre -
commit? (Now this will be probably an option for committers only though)
3) Probably we can add also
{code:java}
ant realclean && ant jar build-test{code}
after applying a patch to a branch as per our [commit
process|https://cassandra.apache.org/_/development/how_to_commit.html]?
4) Why is this in cassandra-builds? I know we try to move to in-tree as much as
possible, though I understand that the it can drift in time between branches.
But I wouldn't expect that to be an issue as since the 3 years and a half I am
working on Cassandra we didn't change anything in the merge strategy even once.
---
Started running the 3.0 script and got an error:
{code:java}
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(dc550dfdc7870b5f176487467e588f320d5b8c8e)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(c0bf31779b9c30765bb06191788953ccce46b9cb)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(eaa9ad32af1b460dec1a02c7184798b42ce0aecd)
error: your index file is unmerged.
fatal: cherry-pick failed
{code}
was (Author: e.dimitrova):
I can run it on a Mac.
Just a few initial thoughts while reading it here:
1) Why do you cherry-pick at all CircleCI changes which are throwaway commit?
2) I am wondering, do we want maybe to add a dry-run -n option for the script?
Potentially with git diff or so to encourage people to verify changes pre -
commit? (Now this will be probably an option for committers only though)
3) Probably we can add also
{code:java}
ant realclean && ant jar build-test{code}
after applying a patch to a branch as per our [commit
process|https://cassandra.apache.org/_/development/how_to_commit.html]?
4) Why is this in cassandra-builds? I know we try to move to in-tree as much as
possible, though I understand that the it can drift in time between branches.
But I wouldn't expect that to be an issue as since the 3 years and a half I am
working on Cassandra we didn't change anything in the merge strategy even once.
Started running the 3.0 script and got an error:
{code:java}
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(dc550dfdc7870b5f176487467e588f320d5b8c8e)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(c0bf31779b9c30765bb06191788953ccce46b9cb)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(eaa9ad32af1b460dec1a02c7184798b42ce0aecd)
error: your index file is unmerged.
fatal: cherry-pick failed
{code}
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circle
[jira] [Commented] (CASSANDRA-18399) Add simple helper script for commiting a change to multiple branches
[
https://issues.apache.org/jira/browse/CASSANDRA-18399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709019#comment-17709019
]
Ekaterina Dimitrova commented on CASSANDRA-18399:
-
I can run it on a Mac.
Just a few initial thoughts while reading it here:
1) Why do you cherry-pick at all CircleCI changes which are throwaway commit?
2) I am wondering, do we want maybe to add a dry-run -n option for the script?
Potentially with git diff or so to encourage people to verify changes pre -
commit? (Now this will be probably an option for committers only though)
3) Probably we can add also
{code:java}
ant realclean && ant jar build-test{code}
after applying a patch to a branch as per our [commit
process|https://cassandra.apache.org/_/development/how_to_commit.html]?
4) Why is this in cassandra-builds? I know we try to move to in-tree as much as
possible, though I understand that the it can drift in time between branches.
But I wouldn't expect that to be an issue as since the 3 years and a half I am
working on Cassandra we didn't change anything in the merge strategy even once.
Started running the 3.0 script and got an error:
{code:java}
git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(dc550dfdc7870b5f176487467e588f320d5b8c8e)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(c0bf31779b9c30765bb06191788953ccce46b9cb)
src/java/org/apache/cassandra/db/SystemKeyspace.java: unmerged
(eaa9ad32af1b460dec1a02c7184798b42ce0aecd)
error: your index file is unmerged.
fatal: cherry-pick failed
{code}
> Add simple helper script for commiting a change to multiple branches
>
>
> Key: CASSANDRA-18399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18399
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Low
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is just a simple additional script which committers can use to help them
> merge commits, especially if the change applies to multiple Cassandra
> versions.
> For example, for CASSANDRA-18153, which applies to 3.0..trunk, it generates
> the following commands, which then can be run manually:
> {noformat}
> git fetch origin
> git fetch jacek-lewandowski
> # jacek-lewandowski/CASSANDRA-18153-3.0 -> cassandra-3.0
> #
>
> git switch cassandra-3.0
> git reset --hard origin/cassandra-3.0
> git cherry-pick e7e9b42559 # e7e9b42559 Save host id to system.local and
> flush immediately after startup
> git cherry-pick -n 99e96a4f95 && git commit -a --amend --no-edit # 99e96a4f95
> fixes
> git cherry-pick -n c63e3f29f1 && git commit -a --amend --no-edit # c63e3f29f1
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^[0-9]+\.[0-9]+/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.0..HEAD -- .circleci/ | git apply -R --index) &&
> git commit -a --amend --no-edit # Remove all changes in .circleci directory
> if you need to
> git diff --name-only origin/cassandra-3.0..HEAD # print a list of all changes
> files
> # jacek-lewandowski/CASSANDRA-18153-3.11 -> cassandra-3.11
> #
>
> git switch cassandra-3.11
> git reset --hard origin/cassandra-3.11
> git merge -s ours --log --no-edit cassandra-3.0
> git cherry-pick -n 79e7b90c8f && git commit -a --amend --no-edit # 79e7b90c8f
> Save host id to system.local and flush immediately after startup
> git cherry-pick -n bdca4c384b && git commit -a --amend --no-edit # bdca4c384b
> fixes
> git cherry-pick -n 45078e6793 && git commit -a --amend --no-edit # 45078e6793
> DO NOT MERGE - CircleCI config
> grep 'CASSANDRA-18153' CHANGES.txt || sed -E -i '/^Merged from 3.0/{s/.*/&\n\
> * Save host id to system.local and flush immediately after startup
> (CASSANDRA-18153)/;:a;n;ba}' CHANGES.txt
> git diff CHANGES.txt
> git add CHANGES.txt
> git commit --amend --no-edit
> (git diff origin/cassandra-3.11..HEAD -- .circleci/ | git apply -R --index)
> && git commit -a --amend --no-edit # Remove all changes in .circleci
> directory if you need to
> git diff --name-only origin/cassandra-3.11..HEAD # print a list of all
> changes files
> # jacek-lewandowski/CASSANDRA-18153-4.0 -> cassandra-4.0
> #
> --
[jira] [Commented] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709018#comment-17709018
]
Claude Warren commented on CASSANDRA-12937:
---
Your's is tested and fixed so let's go with that.
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-18377) CEP-15 (Accord) AsyncOperation can not fail as it has already reached FINISHED
[
https://issues.apache.org/jira/browse/CASSANDRA-18377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18377:
--
Resolution: Fixed
Status: Resolved (was: Open)
CASSANDRA-18422 improved burn test to better mimic C*'s implementation and in
doing so found the same issue, just with a different task class (AsyncOperation
is in C*, so burn test can't use; they are logically the same). The error
found in burn test is that ReadData is seeing duplicate calls to readComplete
for the same store, which is fixed in CASSANDRA-18364.
Once CASSANDRA-18364 merges, if this issue comes back, we can reopen; for now
it looks like CASSANDRA-18364 solves
> CEP-15 (Accord) AsyncOperation can not fail as it has already reached FINISHED
> --
>
> Key: CASSANDRA-18377
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18377
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> java.lang.IllegalArgumentException: Unexpected state FINISHED
> at accord.utils.Invariants.illegalArgument(Invariants.java:54)
> at accord.utils.Invariants.checkArgument(Invariants.java:202)
> at
> org.apache.cassandra.service.accord.async.AsyncOperation.fail(AsyncOperation.java:182)
> at
> org.apache.cassandra.service.accord.async.AsyncOperation.run(AsyncOperation.java:273)
> {code}
> And
> {code}
> java.lang.IllegalArgumentException: Unexpected state FINISHED
> at accord.utils.Invariants.illegalArgument(Invariants.java:54)
> at accord.utils.Invariants.checkArgument(Invariants.java:202)
> at
> org.apache.cassandra.service.accord.async.AsyncOperation.fail(AsyncOperation.java:182)
> at
> org.apache.cassandra.service.accord.async.AsyncOperation.run(AsyncOperation.java:273)
> at
> org.apache.cassandra.service.accord.async.AsyncOperation.callback(AsyncOperation.java:157)
> at
> accord.utils.async.AsyncCallbacks.lambda$null$0(AsyncCallbacks.java:31)
> {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-18422) CEP-15 (Accord) Original and recover coordinators may hit a race condition with PreApply where reads and writes are interleaved, causing one of the coordinators to
[
https://issues.apache.org/jira/browse/CASSANDRA-18422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709004#comment-17709004
]
David Capwell commented on CASSANDRA-18422:
---
patch pulls some things from CASSANDRA-18364 to allow both to go in parallel.
I improved burn tests to hit the issue that this JIRA reports and that also
finds bugs resolved by CASSANDRA-18364
It is possible that 18364 is solved by CASSANDRA-18377 due to the fact a new
similar issues pops up in burn tests (they can't use AsyncOperation as that's
in C*)
{code}
java.lang.IllegalStateException: Result has already been set on
accord.impl.basic.TaskExecutorService$Task@709cd47b
at
accord.utils.async.AsyncResult$Settable.setFailure(AsyncResult.java:83)
at
accord.impl.basic.TaskExecutorService$Task.run(TaskExecutorService.java:53)
at accord.impl.basic.Cluster.processNext(Cluster.java:176)
at accord.impl.basic.Cluster.processPending(Cluster.java:124)
at accord.impl.basic.Cluster.run(Cluster.java:242)
at accord.burn.BurnTest.burn(BurnTest.java:278)
at accord.burn.BurnTest.run(BurnTest.java:350)
at accord.burn.BurnTest.testOne(BurnTest.java:338)
Suppressed: java.lang.IllegalStateException: Txn [1,118,3,1]'s waiting
on does not contain store 7; waitingOn={6}
at accord.utils.Invariants.illegalState(Invariants.java:44)
at accord.utils.Invariants.checkState(Invariants.java:139)
at accord.messages.ReadData.readComplete(ReadData.java:265)
{code}
For that reason ill mark CASSANDRA-18377 as a dup of CASSANDRA-18364
> CEP-15 (Accord) Original and recover coordinators may hit a race condition
> with PreApply where reads and writes are interleaved, causing one of the
> coordinators to see the writes from the other
> -
>
> Key: CASSANDRA-18422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18422
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While verifying CASSANDRA-18364 I saw the following history violation in
> simulator
> {code}
> [junit-timeout] Testcase:
> simulationTest(org.apache.cassandra.simulator.test.ShortAccordSimulationTest)-.jdk1.8:
> Caused an ERROR
> [junit-timeout] Failed on seed 0xadaca81151490353
> [junit-timeout] org.apache.cassandra.simulator.SimulationException: Failed on
> seed 0xadaca81151490353
> [junit-timeout] Caused by: java.lang.AssertionError: History violations
> detected
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.logAndThrow(PaxosSimulation.java:315)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.isDone(PaxosSimulation.java:278)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation$2.hasNext(PaxosSimulation.java:249)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:224)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.run(AbstractPairOfSequencesPaxosSimulation.java:297)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PairOfSequencesAccordSimulation.run(PairOfSequencesAccordSimulation.java:62)
> [junit-timeout] at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:374)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:39)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:30)
> [junit-timeout] at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:355)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner.main(AccordSimulationRunner.java:76)
> [junit-timeout] at
> org.apache.cassandra.simulator.test.ShortAccordSimulationTest.simulationTest(ShortAccordSimulationTest.java:32)
> [junit-timeout] Suppressed:
> org.apache.cassandra.simulator.paxos.HistoryViolation: Inconsistent sequences
> on 1: [2, 0, 1, 6, 8, 9, 13, 14, 16, 19, 20, 22, 23, 25, 26, 28, 29, 31, 32,
> 34, 35, 37, 40, 43, 47, 48, 49, 54, 56, 57, 58, 60, 64, 68, 70, 71, 74, 76,
> 79, 80, 83, 85, 87, 87] vs [2, 0, 1, 6, 8, 9, 13, 14, 16, 19, 20, 22, 23, 25,
> 26, 28, 29, 31, 32, 34, 35, 3
[jira] [Updated] (CASSANDRA-18422) CEP-15 (Accord) Original and recover coordinators may hit a race condition with PreApply where reads and writes are interleaved, causing one of the coordinators to s
[
https://issues.apache.org/jira/browse/CASSANDRA-18422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18422:
--
Reviewers: Ariel Weisberg (was: Ariel Weisberg, David Capwell)
> CEP-15 (Accord) Original and recover coordinators may hit a race condition
> with PreApply where reads and writes are interleaved, causing one of the
> coordinators to see the writes from the other
> -
>
> Key: CASSANDRA-18422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18422
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While verifying CASSANDRA-18364 I saw the following history violation in
> simulator
> {code}
> [junit-timeout] Testcase:
> simulationTest(org.apache.cassandra.simulator.test.ShortAccordSimulationTest)-.jdk1.8:
> Caused an ERROR
> [junit-timeout] Failed on seed 0xadaca81151490353
> [junit-timeout] org.apache.cassandra.simulator.SimulationException: Failed on
> seed 0xadaca81151490353
> [junit-timeout] Caused by: java.lang.AssertionError: History violations
> detected
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.logAndThrow(PaxosSimulation.java:315)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.isDone(PaxosSimulation.java:278)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation$2.hasNext(PaxosSimulation.java:249)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:224)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.run(AbstractPairOfSequencesPaxosSimulation.java:297)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PairOfSequencesAccordSimulation.run(PairOfSequencesAccordSimulation.java:62)
> [junit-timeout] at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:374)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:39)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:30)
> [junit-timeout] at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:355)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner.main(AccordSimulationRunner.java:76)
> [junit-timeout] at
> org.apache.cassandra.simulator.test.ShortAccordSimulationTest.simulationTest(ShortAccordSimulationTest.java:32)
> [junit-timeout] Suppressed:
> org.apache.cassandra.simulator.paxos.HistoryViolation: Inconsistent sequences
> on 1: [2, 0, 1, 6, 8, 9, 13, 14, 16, 19, 20, 22, 23, 25, 26, 28, 29, 31, 32,
> 34, 35, 37, 40, 43, 47, 48, 49, 54, 56, 57, 58, 60, 64, 68, 70, 71, 74, 76,
> 79, 80, 83, 85, 87, 87] vs [2, 0, 1, 6, 8, 9, 13, 14, 16, 19, 20, 22, 23, 25,
> 26, 28, 29, 31, 32, 34, 35, 37, 40, 43, 47, 48, 49, 54, 56, 57, 58, 60, 64,
> 68, 70, 71, 74, 76, 79, 80, 83, 85, 87]+90
> [junit-timeout] at
> accord.verify.StrictSerializabilityVerifier$Register.updateSequence(StrictSerializabilityVerifier.java:607)
> [junit-timeout] at
> accord.verify.StrictSerializabilityVerifier$Register.access$100(StrictSerializabilityVerifier.java:576)
> [junit-timeout] at
> accord.verify.StrictSerializabilityVerifier.apply(StrictSerializabilityVerifier.java:825)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator$1.lambda$close$0(StrictSerializabilityValidator.java:66)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator.convertHistoryViolation(StrictSerializabilityValidator.java:89)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator.access$200(StrictSerializabilityValidator.java:27)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator$1.close(StrictSerializabilityValidator.java:66)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.LoggingHistoryValidator$1.close(LoggingHistoryValidator.java:63)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PairOfSequencesAccordSimulation$ReadWriteOperation.veri
[jira] [Updated] (CASSANDRA-18422) CEP-15 (Accord) Original and recover coordinators may hit a race condition with PreApply where reads and writes are interleaved, causing one of the coordinators to s
[
https://issues.apache.org/jira/browse/CASSANDRA-18422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18422:
--
Reviewers: Ariel Weisberg, David Capwell
Status: Review In Progress (was: Patch Available)
> CEP-15 (Accord) Original and recover coordinators may hit a race condition
> with PreApply where reads and writes are interleaved, causing one of the
> coordinators to see the writes from the other
> -
>
> Key: CASSANDRA-18422
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18422
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 5.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While verifying CASSANDRA-18364 I saw the following history violation in
> simulator
> {code}
> [junit-timeout] Testcase:
> simulationTest(org.apache.cassandra.simulator.test.ShortAccordSimulationTest)-.jdk1.8:
> Caused an ERROR
> [junit-timeout] Failed on seed 0xadaca81151490353
> [junit-timeout] org.apache.cassandra.simulator.SimulationException: Failed on
> seed 0xadaca81151490353
> [junit-timeout] Caused by: java.lang.AssertionError: History violations
> detected
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.logAndThrow(PaxosSimulation.java:315)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.isDone(PaxosSimulation.java:278)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation$2.hasNext(PaxosSimulation.java:249)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PaxosSimulation.run(PaxosSimulation.java:224)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AbstractPairOfSequencesPaxosSimulation.run(AbstractPairOfSequencesPaxosSimulation.java:297)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PairOfSequencesAccordSimulation.run(PairOfSequencesAccordSimulation.java:62)
> [junit-timeout] at
> org.apache.cassandra.simulator.SimulationRunner$Run.run(SimulationRunner.java:374)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:39)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner$Run.run(AccordSimulationRunner.java:30)
> [junit-timeout] at
> org.apache.cassandra.simulator.SimulationRunner$BasicCommand.run(SimulationRunner.java:355)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.AccordSimulationRunner.main(AccordSimulationRunner.java:76)
> [junit-timeout] at
> org.apache.cassandra.simulator.test.ShortAccordSimulationTest.simulationTest(ShortAccordSimulationTest.java:32)
> [junit-timeout] Suppressed:
> org.apache.cassandra.simulator.paxos.HistoryViolation: Inconsistent sequences
> on 1: [2, 0, 1, 6, 8, 9, 13, 14, 16, 19, 20, 22, 23, 25, 26, 28, 29, 31, 32,
> 34, 35, 37, 40, 43, 47, 48, 49, 54, 56, 57, 58, 60, 64, 68, 70, 71, 74, 76,
> 79, 80, 83, 85, 87, 87] vs [2, 0, 1, 6, 8, 9, 13, 14, 16, 19, 20, 22, 23, 25,
> 26, 28, 29, 31, 32, 34, 35, 37, 40, 43, 47, 48, 49, 54, 56, 57, 58, 60, 64,
> 68, 70, 71, 74, 76, 79, 80, 83, 85, 87]+90
> [junit-timeout] at
> accord.verify.StrictSerializabilityVerifier$Register.updateSequence(StrictSerializabilityVerifier.java:607)
> [junit-timeout] at
> accord.verify.StrictSerializabilityVerifier$Register.access$100(StrictSerializabilityVerifier.java:576)
> [junit-timeout] at
> accord.verify.StrictSerializabilityVerifier.apply(StrictSerializabilityVerifier.java:825)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator$1.lambda$close$0(StrictSerializabilityValidator.java:66)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator.convertHistoryViolation(StrictSerializabilityValidator.java:89)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator.access$200(StrictSerializabilityValidator.java:27)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.StrictSerializabilityValidator$1.close(StrictSerializabilityValidator.java:66)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.LoggingHistoryValidator$1.close(LoggingHistoryValidator.java:63)
> [junit-timeout] at
> org.apache.cassandra.simulator.paxos.PairOfSequencesAccor
[jira] [Comment Edited] (CASSANDRA-18352) Add Option to Timebox write timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708984#comment-17708984
]
Andres de la Peña edited comment on CASSANDRA-18352 at 4/5/23 4:11 PM:
---
Thanks, I have left a few additional suggestions on the PR.
It seems that the CI runs don't include repeated runs for the new and modified
tests. Those repeated runs can be included on CircleCI config by running:
{code:java}
.circleci/generate.sh -p
{code}
I think the dtest failures about not existing CQL functions are due to
CASSANDRA-18037. CI is using the current dtest branch that uses the new
function names, whereas the tested branch doesn't include them. Hopefully the
failures will go away after rebasing.
was (Author: adelapena):
Thanks, I have left a few additional suggestions on the PR.
It seems that the CI runs don't include repeated runs for the new and modified
tests. Those repeated runs can be included on CircleCI config by running:
{code}
.circleci/generate.sh -p
{code}
> Add Option to Timebox write timestamps
> --
>
> Key: CASSANDRA-18352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18352
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> In several cases it is desirable to have client provided timestamps generated
> at the application-level. This can be error prone, however. In particular,
> applications can choose timestamps that may be nonsensical for a given
> application. One dangerous manifestation of this is the "doomstone" (a
> tombstone far in the future of any realistic write). This feature would allow
> either operators or users to specify a minimum and maximum timebound of
> "reasonable" timestamps. The default would be negative infinity, positive
> infinity to maintain backwards compatibility. Writes that are USING TIMESTAMP
> with a timestamp outside of the timebox will see an exception.
--
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-builds] branch CASSANDRA-18401 created (now d6cec22)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch CASSANDRA-18401 in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git at d6cec22 Add specifc versions for ccm This branch includes the following new commits: new d6cec22 Add specifc versions for ccm 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] 01/01: Add specifc versions for ccm
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch CASSANDRA-18401 in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git commit d6cec22f39f57e89b13c201fe525be4f2b8799ac Author: Brandon Williams AuthorDate: Wed Apr 5 11:08:40 2023 -0500 Add specifc versions for ccm --- docker/testing/ubuntu2004_j11_w_dependencies.docker | 12 1 file changed, 12 insertions(+) diff --git a/docker/testing/ubuntu2004_j11_w_dependencies.docker b/docker/testing/ubuntu2004_j11_w_dependencies.docker index f79ffec..5d78a4a 100644 --- a/docker/testing/ubuntu2004_j11_w_dependencies.docker +++ b/docker/testing/ubuntu2004_j11_w_dependencies.docker @@ -40,3 +40,15 @@ RUN /bin/bash -c "source ~/env3.6/bin/activate && \ ccm create -n 1 -v git:cassandra-3.0 test && ccm remove test && \ ccm create -n 1 -v git:cassandra-2.2 test && ccm remove test && \ ccm create -n 1 -v git:cassandra-2.1 test && ccm remove test" + +# Initialize specific versions pulled in for testing +RUN /bin/bash -c "source ~/env3.6/bin/activate && \ +ccm create -n 1 -v 2.1.14 test && ccm remove test && \ +ccm create -n 1 -v 2.1.22 test && ccm remove test && \ +ccm create -n 1 -v 2.2.19 test && ccm remove test && \ +ccm create -n 1 -v 3.0.17 test && ccm remove test && \ +ccm create -n 1 -v 3.0.27 test && ccm remove test && \ +ccm create -n 1 -v 3.11.3 test && ccm remove test && \ +ccm create -n 1 -v 3.11.13 test && ccm remove test && \ +ccm create -n 1 -v 4.0.4 test && ccm remove test" + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18352) Add Option to Timebox write timestamps
[
https://issues.apache.org/jira/browse/CASSANDRA-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708984#comment-17708984
]
Andres de la Peña commented on CASSANDRA-18352:
---
Thanks, I have left a few additional suggestions on the PR.
It seems that the CI runs don't include repeated runs for the new and modified
tests. Those repeated runs can be included on CircleCI config by running:
{code}
.circleci/generate.sh -p
{code}
> Add Option to Timebox write timestamps
> --
>
> Key: CASSANDRA-18352
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18352
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> In several cases it is desirable to have client provided timestamps generated
> at the application-level. This can be error prone, however. In particular,
> applications can choose timestamps that may be nonsensical for a given
> application. One dangerous manifestation of this is the "doomstone" (a
> tombstone far in the future of any realistic write). This feature would allow
> either operators or users to specify a minimum and maximum timebound of
> "reasonable" timestamps. The default would be negative infinity, positive
> infinity to maintain backwards compatibility. Writes that are USING TIMESTAMP
> with a timestamp outside of the timebox will see an exception.
--
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-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708973#comment-17708973 ] Caleb Rackliffe edited comment on CASSANDRA-18124 at 4/5/23 3:50 PM: - +1 (w/ some minor conversations to wrap up in the PR) The two test failures that popped up are a timeout and a 2i building failure, neither of which have anything to do w/ this patch. was (Author: maedhroz): +1 (w/ some minor conversations to wrap up in the PR) > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708977#comment-17708977
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
{quote}On startup I see more storage consumption reported.
{quote}
That is actually interesting, now I see different numbers when I switched back
to latest trunk.
Might be just my setup and cleaning between branches/commits playing me
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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] [Comment Edited] (CASSANDRA-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708940#comment-17708940 ] Brandon Williams edited comment on CASSANDRA-18249 at 4/5/23 3:45 PM: -- Are we good with committing the change to use createrepo_c and closing? was (Author: brandon.williams): Are we good with committing the change to use creaetrepo_c and closing? > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.9, 5.0 > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18249: - Fix Version/s: 3.0.29 3.11.15 4.0.9 5.0 Source Control Link: https://github.com/apache/cassandra-builds/commit/dd33b24808310a36f51c41361ec9d82a76f88afe Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed. > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 3.0.x, 3.11.x, 4.0.9, 4.0.x, 4.1.x, > 5.0, 5.x > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18249: - Fix Version/s: (was: 3.0.x) (was: 3.11.x) (was: 5.x) (was: 4.0.x) (was: 4.1.x) > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.29, 3.11.15, 4.0.9, 5.0 > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708974#comment-17708974
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
So there are two things. On startup I see more storage consumption reported.
With the new measurements added when we initialize the Murmur3Partitioner it
hits those internals mentioned in the stack trace which is jamm problem
triggered by new measuring added in CASSANDRA-17199
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708973#comment-17708973 ] Caleb Rackliffe commented on CASSANDRA-18124: - +1 (w/ some minor conversations to wrap up in the PR) > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18249: - Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18249: - Status: Ready to Commit (was: Review In Progress) > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18249: - Test and Documentation Plan: not needed Status: Patch Available (was: Open) > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-builds] branch trunk updated: Change to createrepo_c in prepare_releash.sh
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/trunk by this push:
new dd33b24 Change to createrepo_c in prepare_releash.sh
dd33b24 is described below
commit dd33b24808310a36f51c41361ec9d82a76f88afe
Author: Brandon Williams
AuthorDate: Wed Apr 5 10:41:05 2023 -0500
Change to createrepo_c in prepare_releash.sh
Patch by brandonwilliams; reviewed by mck for CASSANDRA-18249
---
cassandra-release/prepare_release.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cassandra-release/prepare_release.sh
b/cassandra-release/prepare_release.sh
index 6beedff..2fc5ee9 100755
--- a/cassandra-release/prepare_release.sh
+++ b/cassandra-release/prepare_release.sh
@@ -27,7 +27,7 @@ command -v debsign >/dev/null 2>&1 || { echo >&2 "devscripts
needs to be install
command -v reprepro >/dev/null 2>&1 || { echo >&2 "reprepro needs to be
installed"; exit 1; }
command -v rpmsign >/dev/null 2>&1 || { echo >&2 "rpmsign needs to be
installed"; exit 1; }
command -v docker >/dev/null 2>&1 || { echo >&2 "docker needs to be
installed"; exit 1; }
-command -v createrepo >/dev/null 2>&1 || { echo >&2 "createrepo needs to be
installed"; exit 1; }
+command -v createrepo_c >/dev/null 2>&1 || { echo >&2 "createrepo_c needs to
be installed"; exit 1; }
(docker info >/dev/null 2>&1) || { echo >&2 "docker needs to running"; exit 1;
}
###
@@ -341,7 +341,7 @@ then
execute "mkdir $tmp_dir/cassandra-dist-dev/${release}/redhat"
execute "cp ${rpm_dir}/*.rpm
$tmp_dir/cassandra-dist-dev/${release}/redhat/"
execute "cd $tmp_dir/cassandra-dist-dev/${release}/redhat/"
-execute "createrepo ."
+execute "createrepo_c ."
# FIXME - put into execute "…"
[ $fake_mode -eq 1 ] || for f in repodata/repomd.xml repodata/*.bz2
repodata/*.gz ; do gpg --detach-sign --armor $f ; done
@@ -369,7 +369,7 @@ then
execute "mkdir $tmp_dir/cassandra-dist-dev/${release}/redhat/noboolean"
execute "cp ${rpm_dir}/*.rpm
$tmp_dir/cassandra-dist-dev/${release}/redhat/noboolean"
execute "cd $tmp_dir/cassandra-dist-dev/${release}/redhat/noboolean"
-execute "createrepo ."
+execute "createrepo_c ."
# FIXME - put into execute "…"
[ $fake_mode -eq 1 ] || for f in repodata/repomd.xml repodata/*.bz2
repodata/*.gz ; do gpg --detach-sign --armor $f ; done
fi
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708964#comment-17708964 ] Michael Semb Wever commented on CASSANDRA-18249: bq. Are we good with committing the change to use creaetrepo_c and closing? +1 > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-18427) Test failure: pdtest: dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
[
https://issues.apache.org/jira/browse/CASSANDRA-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-18427:
Assignee: Brandon Williams
> Test failure: pdtest:
> dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
>
>
> Key: CASSANDRA-18427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18427
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
>
> {{Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%}}
> {code}
> Error Message
> AssertionError: Expected [[1, 1, None, None], [2, 2, None, None]] from SELECT
> * FROM ttl_table;, but got [[2, 2, None, None]]
> Stacktrace
> self =
> def test_ttl_is_respected_on_delayed_replication(self):
> """ Test that ttl is respected on delayed replication """
> self.prepare()
> self.node2.stop()
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (1, 1) USING TTL 5;
> """)
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (2, 2) USING TTL 1000;
> """)
> > assert_all(
> self.session1,
> "SELECT * FROM ttl_table;",
> [[1, 1, None, None], [2, 2, None, None]]
> )
> ttl_test.py:480:
> {code}
> At face value this didn't look like a classic "oops I timed out", but now
> that I read that error message I'm not as sure. So I'd check that first and
> just close out if it's a timeout by another name until we get the infra
> stabilized.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708954#comment-17708954 ] Maxim Muzafarov edited comment on CASSANDRA-18262 at 4/5/23 3:26 PM: - I feel something strange about the statement "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". We do JUnit tests for j11, j17 now, right? Why shouldn't we do source (or other) checks for these versions using the same logic? I would say that if we not follow these assumptions, we should remove j11,j17 from the running configuration of CI, just to avoid anyone getting confused (which is bad). The checkstyle is just the source code test, I don't think we should force it to run only on j11 while other tests run on j11 and j17. was (Author: mmuzaf): I feel something strange about the statement "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". We do JUnit tests for j11, j17 now, right? Why shouldn't we do source (or other) checks for these versions using the same logic? I would say that if we not follow these assumptions, we should remove j11,j17 from the running configuration of CI, just to avoid anyone getting confused (which is bad). The checkstyle is just the source code test, I don't think we should force it to run only on j11 if other tests also run on j11 and j17. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18427) Test failure: pdtest: dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
[
https://issues.apache.org/jira/browse/CASSANDRA-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18427:
-
Mentor: (was: maxime tremblay)
> Test failure: pdtest:
> dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
>
>
> Key: CASSANDRA-18427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18427
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
>
> {{Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%}}
> {code}
> Error Message
> AssertionError: Expected [[1, 1, None, None], [2, 2, None, None]] from SELECT
> * FROM ttl_table;, but got [[2, 2, None, None]]
> Stacktrace
> self =
> def test_ttl_is_respected_on_delayed_replication(self):
> """ Test that ttl is respected on delayed replication """
> self.prepare()
> self.node2.stop()
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (1, 1) USING TTL 5;
> """)
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (2, 2) USING TTL 1000;
> """)
> > assert_all(
> self.session1,
> "SELECT * FROM ttl_table;",
> [[1, 1, None, None], [2, 2, None, None]]
> )
> ttl_test.py:480:
> {code}
> At face value this didn't look like a classic "oops I timed out", but now
> that I read that error message I'm not as sure. So I'd check that first and
> just close out if it's a timeout by another name until we get the infra
> stabilized.
--
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-18427) Test failure: pdtest: dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
[
https://issues.apache.org/jira/browse/CASSANDRA-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18427:
-
Resolution: Cannot Reproduce
Status: Resolved (was: Triage Needed)
Resolving as cannot repro.
> Test failure: pdtest:
> dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
>
>
> Key: CASSANDRA-18427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18427
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
>
> {{Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%}}
> {code}
> Error Message
> AssertionError: Expected [[1, 1, None, None], [2, 2, None, None]] from SELECT
> * FROM ttl_table;, but got [[2, 2, None, None]]
> Stacktrace
> self =
> def test_ttl_is_respected_on_delayed_replication(self):
> """ Test that ttl is respected on delayed replication """
> self.prepare()
> self.node2.stop()
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (1, 1) USING TTL 5;
> """)
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (2, 2) USING TTL 1000;
> """)
> > assert_all(
> self.session1,
> "SELECT * FROM ttl_table;",
> [[1, 1, None, None], [2, 2, None, None]]
> )
> ttl_test.py:480:
> {code}
> At face value this didn't look like a classic "oops I timed out", but now
> that I read that error message I'm not as sure. So I'd check that first and
> just close out if it's a timeout by another name until we get the infra
> stabilized.
--
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-18427) Test failure: pdtest: dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
[
https://issues.apache.org/jira/browse/CASSANDRA-18427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708957#comment-17708957
]
Brandon Williams commented on CASSANDRA-18427:
--
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/955/workflows/ad33d42f-fa93-4331-b716-68d01138e324/jobs/19120]
is 500 runs in circle (against trunk, which may be correct?) that
unsurprisingly did not reproduce. I believe this was just a timeout, since the
record with a TTL of 5 is not present, but the one with the longer TTL of 1000
is.
> Test failure: pdtest:
> dtest-novnode.ttl_test.TestDistributedTTL.test_ttl_is_respected_on_delayed_replication
>
>
> Key: CASSANDRA-18427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18427
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Priority: Normal
>
> {{Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96%}}
> {code}
> Error Message
> AssertionError: Expected [[1, 1, None, None], [2, 2, None, None]] from SELECT
> * FROM ttl_table;, but got [[2, 2, None, None]]
> Stacktrace
> self =
> def test_ttl_is_respected_on_delayed_replication(self):
> """ Test that ttl is respected on delayed replication """
> self.prepare()
> self.node2.stop()
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (1, 1) USING TTL 5;
> """)
> self.session1.execute("""
> INSERT INTO ttl_table (key, col1) VALUES (2, 2) USING TTL 1000;
> """)
> > assert_all(
> self.session1,
> "SELECT * FROM ttl_table;",
> [[1, 1, None, None], [2, 2, None, None]]
> )
> ttl_test.py:480:
> {code}
> At face value this didn't look like a classic "oops I timed out", but now
> that I read that error message I'm not as sure. So I'd check that first and
> just close out if it's a timeout by another name until we get the infra
> stabilized.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708954#comment-17708954 ] Maxim Muzafarov commented on CASSANDRA-18262: - I feel something strange about the statement "Running tests or checks for jdk versions other than the minimum supported jdk version forces someone to do their development, not on that minimum version". We do JUnit tests for j11, j17 now, right? Why shouldn't we do source (or other) checks for these versions using the same logic? I would say that if we not follow these assumptions, we should remove j11,j17 from the running configuration of CI, just to avoid anyone getting confused (which is bad). The checkstyle is just the source code test, I don't think we should force it to run only on j11 if other tests also run on j11 and j17. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708947#comment-17708947
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
I figured that the JDK17 build doesn't start at the moment because of this:
{code:java}
WARN [main] 2023-04-05 10:46:25,361 DatabaseDescriptor.java:675 - Only
44.801GiB free across all data volumes. Consider adding more capacity to your
cluster or removing obsolete snapshots
Exception (java.lang.ExceptionInInitializerError) encountered during startup:
null
java.lang.ExceptionInInitializerError
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
at org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:221)
at org.apache.cassandra.utils.ObjectSizes.(ObjectSizes.java:45)
... 15 more
ERROR [main] 2023-04-05 10:46:26,007 CassandraDaemon.java:910 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
at org.apache.cassandra.utils.ObjectSizes
[jira] [Comment Edited] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708947#comment-17708947
]
Ekaterina Dimitrova edited comment on CASSANDRA-17869 at 4/5/23 3:06 PM:
-
I figured that the JDK17 build doesn't start at the moment because of this (as
expected we do not have too much storage locally and in CI available so we
trigger the below warning):
{code:java}
WARN [main] 2023-04-05 10:46:25,361 DatabaseDescriptor.java:675 - Only
44.801GiB free across all data volumes. Consider adding more capacity to your
cluster or removing obsolete snapshots
Exception (java.lang.ExceptionInInitializerError) encountered during startup:
null
java.lang.ExceptionInInitializerError
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
at org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:221)
at org.apache.cassandra.utils.ObjectSizes.(ObjectSizes.java:45)
... 15 more
ERROR [main] 2023-04-05 10:46:26,007 CassandraDaemon.java:910 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.Me
[jira] [Comment Edited] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708947#comment-17708947
]
Ekaterina Dimitrova edited comment on CASSANDRA-17869 at 4/5/23 3:06 PM:
-
I figured that the JDK17 build doesn't start at the moment because of this (as
expected we do not have too much storage locally and in CI available so we
trigger the below warning):
{code:java}
WARN [main] 2023-04-05 10:46:25,361 DatabaseDescriptor.java:675 - Only
44.801GiB free across all data volumes. Consider adding more capacity to your
cluster or removing obsolete snapshots
Exception (java.lang.ExceptionInInitializerError) encountered during startup:
null
java.lang.ExceptionInInitializerError
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.MemoryMeter.addFieldChildren(MemoryMeter.java:330)
at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:269)
at org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:221)
at org.apache.cassandra.utils.ObjectSizes.(ObjectSizes.java:45)
... 15 more
ERROR [main] 2023-04-05 10:46:26,007 CassandraDaemon.java:910 - Exception
encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.dht.Murmur3Partitioner.(Murmur3Partitioner.java:54)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at org.apache.cassandra.utils.FBUtilities.classForName(FBUtilities.java:721)
at
org.apache.cassandra.utils.FBUtilities.instanceOrConstruct(FBUtilities.java:737)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:642)
at org.apache.cassandra.utils.FBUtilities.newPartitioner(FBUtilities.java:628)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1342)
at
org.apache.cassandra.config.DatabaseDescriptor.applyPartitioner(DatabaseDescriptor.java:1328)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:403)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:216)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:200)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:817)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:760)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:888)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field
private final transient java.net.InetSocketAddress$InetSocketAddressHolder
java.net.InetSocketAddress.holder accessible: module java.base does not "opens
java.net" to unnamed module @536dbea0
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
at org.github.jamm.Me
[jira] [Commented] (CASSANDRA-18249) Docker image for releases
[ https://issues.apache.org/jira/browse/CASSANDRA-18249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708940#comment-17708940 ] Brandon Williams commented on CASSANDRA-18249: -- Are we good with committing the change to use creaetrepo_c and closing? > Docker image for releases > - > > Key: CASSANDRA-18249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18249 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Berenguer Blasi >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > The release process is currently driven bu this > [doc|https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/release_process.adoc] > mainly. > Some of the requirements are a Debian based distro and a number of packages. > As recently discovered this could be a problem, Ubuntu 20.04 LTS doesn't have > createrepo available i.e. > To avoid such problems, add repeatability, have a controlled env where > releases are cut, enable more people to cut them, etc [~mck] suggested > creating a docker image to that purpose probably based off > [this|https://github.com/apache/cassandra-builds/blob/trunk/docker/bullseye-image.docker] -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708941#comment-17708941
]
Josh McKenzie commented on CASSANDRA-18262:
---
bq. Why would you be developing and checking against 11 if you ship with 8 to
get to the point that you broke 8 only when you get to CI?
This is a really good point. This has kind of been nagging at me for years
without bubbling up to the surface.
Is there any reason to develop locally on any JDK other than the oldest one
supported, since we can't use new language features anyway? Is the thought that
the newer JDKs would potentially build faster or run local tests faster to
tighten the feedback loops working on code/
Currently our documentation
[link|https://cassandra.apache.org/_/development/index.html] kind of hand-waves
at the situation as being up to the individual developer:
{quote}
Prerequisites
Building Cassandra from source is the first important step in contributing to
the Apache Cassandra project. You will need to install Java (JDK 8 or 11,
depending on which version you want to build Cassandra against, best is to
install both and then switch between them when needed), Git, and Ant (including
ant-optional).
{quote}
It seems to me that we could have stronger verbiage along the lines of "We
recommend you build and run locally on the oldest supported JDK version X as
newer language features cannot be supported due to compilation requirements."
> Switch checkstyle running only with JDK8 to be run with JDK11
> -
>
> Key: CASSANDRA-18262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18262
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we run checkstyle, eclipse warnings (and probably anything else?)
> only with JDK8.
> In preparation to remove JDK8 we need to switch those to run with JDK11.
--
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-18373) Node Draining Should Abort All Current SSTables Imports
[ https://issues.apache.org/jira/browse/CASSANDRA-18373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708911#comment-17708911 ] Yuriy Semchyshyn commented on CASSANDRA-18373: -- Thanks for the review, Dinesh! Addressed your comments in a separate commit. > Node Draining Should Abort All Current SSTables Imports > --- > > Key: CASSANDRA-18373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18373 > Project: Cassandra > Issue Type: Improvement > Components: Local/Startup and Shutdown >Reporter: Yuriy Semchyshyn >Assignee: Yuriy Semchyshyn >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > SS tables imports that will end up being ignored due to the node draining > should fail instead of succeeding. > Each active SS tables import should periodically check for the node status > and see whether or not it is `DRAINING`. > In case the node starts draining the import should abort immediately by > throwing an `InterruptedException`. -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708899#comment-17708899
]
Michael Semb Wever commented on CASSANDRA-17869:
CI
- artifacts: http://13.50.248.249:8080/job/Cassandra-trunk-artifacts/21/
- cqlsh-tests: …wip…
- unit: http://13.50.248.249:8080/job/Cassandra-trunk-test/4/
- jvm-dtest: http://13.50.248.249:8080/job/Cassandra-trunk-jvm-dtest/4/
- jvm-dtest-upgrade:
http://13.50.248.249:8080/job/Cassandra-trunk-jvm-dtest-upgrade/2/
- dtest: http://13.50.248.249:8080/job/Cassandra-trunk-dtest/10/
- dtest-upgrade: http://13.50.248.249:8080/job/Cassandra-trunk-dtest-upgrade/1/
Failures are similar to CircleCI:
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra?branch=mck%2Ftrunk
> 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
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> 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-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708896#comment-17708896
]
Stefan Miklosovic commented on CASSANDRA-12937:
---
clean j8 precommit on my branch
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2055/workflows/6e2f2a8a-c8e9-4a9f-a5c9-af9cf6b59b2b
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Claude Warren
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708878#comment-17708878
]
Ekaterina Dimitrova edited comment on CASSANDRA-18262 at 4/5/23 1:20 PM:
-
{quote}{quote}Checkstyle run on Java 11 detects issues in the code regardless
of Java version and it does not have to have anything in common with Java 8.
{quote}{quote}
valid point, yes, but we should not encourage development on newer versions as
you mentioned before. It is one thing to proactively test, it is another to
move to development on newer versions and slow down development and reviews
was (Author: e.dimitrova):
{quote}bq. Checkstyle run on Java 11 detects issues in the code regardless of
Java version and it does not have to have anything in common with Java 8.
{quote}
valid point, yes, but we should not encourage development on newer versions as
you mentioned before. It is one thing to proactively test, it is another to
move to development on newer versions and slow down development
> Switch checkstyle running only with JDK8 to be run with JDK11
> -
>
> Key: CASSANDRA-18262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18262
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we run checkstyle, eclipse warnings (and probably anything else?)
> only with JDK8.
> In preparation to remove JDK8 we need to switch those to run with JDK11.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708885#comment-17708885
]
Stefan Miklosovic edited comment on CASSANDRA-18262 at 4/5/23 1:08 PM:
---
I yet have to see folks using Java 11 APIs {_}heavilly{_}. I do not think we
are actively encouraging them. The only case when Java 11 API was used was the
usage of String.isBlank(). I have never seen any other usages of Java 11 and I
think that it is more or less given that it has to eventually compile to Java
8. People are probably just used to take shortcuts like this out of
convenience. That is something different from them using what Java 11 has to
offer when it comes to its new apis.
was (Author: smiklosovic):
I yet have to see folks using Java 11 APIs. I do not think we are actively
encouraging them. The only case when Java 11 API was used was the usage of
String.isBlank(). I have never seen any other usages of Java 11 and I think
that it is more or less given that it has to eventually compile to Java 8.
People are probably just used to take shortcuts like this out of convenience.
That is something different from them using what Java 11 has to offer when it
comes to its new apis.
> Switch checkstyle running only with JDK8 to be run with JDK11
> -
>
> Key: CASSANDRA-18262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18262
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we run checkstyle, eclipse warnings (and probably anything else?)
> only with JDK8.
> In preparation to remove JDK8 we need to switch those to run with JDK11.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708885#comment-17708885 ] Stefan Miklosovic commented on CASSANDRA-18262: --- I yet have to see folks using Java 11 APIs. I do not think we are actively encouraging them. The only case when Java 11 API was used was the usage of String.isBlank(). I have never seen any other usages of Java 11 and I think that it is more or less given that it has to eventually compile to Java 8. People are probably just used to take shortcuts like this out of convenience. That is something different from them using what Java 11 has to offer when it comes to its new apis. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708878#comment-17708878
]
Ekaterina Dimitrova commented on CASSANDRA-18262:
-
{quote}bq. Checkstyle run on Java 11 detects issues in the code regardless of
Java version and it does not have to have anything in common with Java 8.
{quote}
valid point, yes, but we should not encourage development on newer versions as
you mentioned before. It is one thing to proactively test, it is another to
move to development on newer versions and slow down development
> Switch checkstyle running only with JDK8 to be run with JDK11
> -
>
> Key: CASSANDRA-18262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18262
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we run checkstyle, eclipse warnings (and probably anything else?)
> only with JDK8.
> In preparation to remove JDK8 we need to switch those to run with JDK11.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708871#comment-17708871 ] Stefan Miklosovic commented on CASSANDRA-18262: --- _so if they develop against 11 you will never get 8 compilation issues?_ We definitely minimize the number of issues they might get. Checkstyle run on Java 11 detects issues in the code regardless of Java version and it does not have to have anything in common with Java 8. Illegal imports will be illegal if one is on Java 8 or Java 11, no? As I mentioned, the only thing it would not detect is them using API which are not in Java 8 but that is the problem which exists anyway and is not solvable, currently, by checkstyle as such. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708869#comment-17708869
]
Ekaterina Dimitrova commented on CASSANDRA-18262:
-
{quote}My take is that it is better to have backlog full of checkstyle-valid
patches waiting to be reviewed rather than smaller amount of patches
potentially containing compilation issues in them.
{quote}
so if they develop against 11 you will never get 8 compilation issues?:)
I think we are running in circles here. I made a point that was actually
decided long ago. Let’s agree to disagree. I will be happy with a ML dev thread
as[~jmckenzie] already suggested to change the current agreements
> Switch checkstyle running only with JDK8 to be run with JDK11
> -
>
> Key: CASSANDRA-18262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18262
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we run checkstyle, eclipse warnings (and probably anything else?)
> only with JDK8.
> In preparation to remove JDK8 we need to switch those to run with JDK11.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708864#comment-17708864 ] Ekaterina Dimitrova edited comment on CASSANDRA-18262 at 4/5/23 12:41 PM: -- bq. That is reasonable because we are not supporting Java 17 officially yet. If we officially support Java 11 (right?), why would we restrict them to develop on it with one caveat that it has to compile to Java 8. But having checkstyle triggered on 11 seems like totally innocent thing. Because we agreed on incrementally adding JDK versions and people who are working to fix 11 builds running on 17 will have to figure out every time profile which might be even incorrect, but they don’t know as it was not reviewed:) was (Author: e.dimitrova): Bq. That is reasonable because we are not supporting Java 17 officially yet. If we officially support Java 11 (right?), why would we restrict them to develop on it with one caveat that it has to compile to Java 8. But having checkstyle triggered on 11 seems like totally innocent thing. Because we agreed on incrementally adding JDK versions and people who are working to fix 11 builds running on 17 will have to figure out every time profile which might be even incorrect, but they don’t know as it was not reviewed:) > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708864#comment-17708864 ] Ekaterina Dimitrova commented on CASSANDRA-18262: - Bq. That is reasonable because we are not supporting Java 17 officially yet. If we officially support Java 11 (right?), why would we restrict them to develop on it with one caveat that it has to compile to Java 8. But having checkstyle triggered on 11 seems like totally innocent thing. Because we agreed on incrementally adding JDK versions and people who are working to fix 11 builds running on 17 will have to figure out every time profile which might be even incorrect, but they don’t know as it was not reviewed:) > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708862#comment-17708862 ] Stefan Miklosovic commented on CASSANDRA-18262: --- _I do not question that. I say it is confusing if you check against JDK11 stuff to realize you broke 8 after you put the effort to check yourself against 11._ I do not think we do any difference in our checkstyle rules between Java 8 and Java 11. The checkstyle itself is "version agnostic". It is more about what Java that checkstyle is triggered on. _Isn’t it demotivating people to wait months for their work to be reviewed?_ My take is that it is better to have backlog full of checkstyle-valid patches waiting to be reviewed rather than smaller amount of patches potentially containing compilation issues in them. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708860#comment-17708860 ] Ekaterina Dimitrova edited comment on CASSANDRA-18262 at 4/5/23 12:38 PM: -- By the way we can probably just use the flag for no-checkstyle for builds other than the one we ship Cassandra for CI and leave locally checkstyle to be run with all builds? But I still do not think we should encourage development with other versions was (Author: e.dimitrova): By the way we can probably just use the flag for no-checkstyle for builds other than the one we ship Cassandra for CI and leave locally checkstyle to be run with all builds? > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708860#comment-17708860 ] Ekaterina Dimitrova edited comment on CASSANDRA-18262 at 4/5/23 12:37 PM: -- By the way we can probably just use the flag for no-checkstyle for builds other than the one we ship Cassandra for CI and leave locally checkstyle to be run with all builds? was (Author: e.dimitrova): By the way we can probably just use the flag for no-checkstyle for builds other than the one we deliver in CI and leave locally checkstyle to be run with all builds? > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708853#comment-17708853 ] Stefan Miklosovic edited comment on CASSANDRA-18262 at 4/5/23 12:37 PM: _I think we have too much Patch Available backlog to encourage people to develop and submit patches on other versions, to find out things need to be reworked only with CI and reviews._ This might be resolved just by enabling checkstyle while they are on Java 11? I do not get why having too many patches in backlog is necessarily bad thing. _Honestly, considering the build goes from 1 minute to 3 from what I see in the comments, I fear most people probably even use the option to skip checkstyle many times locally_ But that is entirely on them. My perception is different. They would love to offer valid code before asking somebody to review, definitely. _By the way I had similar discussion with Mick around adding intellij idea target for JDK17 and I was told we should not encourage development against other versions._ That is reasonable because we are not supporting Java 17 officially yet. If we officially support Java 11 (right?), why would we restrict them to develop on it with one caveat that it has to compile to Java 8. But having checkstyle triggered on 11 seems like totally innocent thing. was (Author: smiklosovic): _I think we have too much Patch Available backlog to encourage people to develop and submit patches on other versions, to find out things need to be reworked only with CI and reviews._ This might be resolved just by enabling checkstyle while they are on Java 11? I do not get why having too many patches in backlog is necessarily bad thing. _Honestly, considering the build goes from 1 minute to 3 from what I see in the comments, I fear most people probably even use the option to skip checkstyle many times locally_ But that is entirely on them. My perception is different. They would love to offer valid code before asking somebody to review, definitely. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708860#comment-17708860 ] Ekaterina Dimitrova commented on CASSANDRA-18262: - By the way we can probably just use the flag for no-checkstyle for builds other than the one we deliver in CI and leave locally checkstyle to be run with all builds? > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[
https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708856#comment-17708856
]
Ekaterina Dimitrova commented on CASSANDRA-18262:
-
{quote}bq. They would love to offer valid code before asking somebody to
review, definitely
{quote}
I do not question that. I say it is confusing if you check against JDK11 stuff
to realize you broke 8 after you put the effort to check yourself against 11.
{quote}bq. do not get why having too many patches in backlog is necessarily bad
thing.
{quote}
Isn’t it better to have too many patches committed?:) Isn’t it demotivating
people to wait months for their work to be reviewed?
> Switch checkstyle running only with JDK8 to be run with JDK11
> -
>
> Key: CASSANDRA-18262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18262
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we run checkstyle, eclipse warnings (and probably anything else?)
> only with JDK8.
> In preparation to remove JDK8 we need to switch those to run with JDK11.
--
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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708853#comment-17708853 ] Stefan Miklosovic commented on CASSANDRA-18262: --- _I think we have too much Patch Available backlog to encourage people to develop and submit patches on other versions, to find out things need to be reworked only with CI and reviews. _ This might be resolved just by enabling checkstyle while they are on Java 11? I do not get why having too many patches in backlog is necessarily bad thing. _Honestly, considering the build goes from 1 minute to 3 from what I see in the comments, I fear most people probably even use the option to skip checkstyle many times locally_ But that is entirely on them. My perception is different. They would love to offer valid code before asking somebody to review, definitely. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708853#comment-17708853 ] Stefan Miklosovic edited comment on CASSANDRA-18262 at 4/5/23 12:28 PM: _I think we have too much Patch Available backlog to encourage people to develop and submit patches on other versions, to find out things need to be reworked only with CI and reviews._ This might be resolved just by enabling checkstyle while they are on Java 11? I do not get why having too many patches in backlog is necessarily bad thing. _Honestly, considering the build goes from 1 minute to 3 from what I see in the comments, I fear most people probably even use the option to skip checkstyle many times locally_ But that is entirely on them. My perception is different. They would love to offer valid code before asking somebody to review, definitely. was (Author: smiklosovic): _I think we have too much Patch Available backlog to encourage people to develop and submit patches on other versions, to find out things need to be reworked only with CI and reviews. _ This might be resolved just by enabling checkstyle while they are on Java 11? I do not get why having too many patches in backlog is necessarily bad thing. _Honestly, considering the build goes from 1 minute to 3 from what I see in the comments, I fear most people probably even use the option to skip checkstyle many times locally_ But that is entirely on them. My perception is different. They would love to offer valid code before asking somebody to review, definitely. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708848#comment-17708848 ] Ekaterina Dimitrova commented on CASSANDRA-18262: - By the way I had similar discussion with[~mck] around adding intellij idea target for JDK17 and I was told we should not encourage development against other versions. > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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-18262) Switch checkstyle running only with JDK8 to be run with JDK11
[ https://issues.apache.org/jira/browse/CASSANDRA-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708844#comment-17708844 ] Ekaterina Dimitrova commented on CASSANDRA-18262: - People might be developing against Java 19 in their forks, but IMHO we should focus on what Cassandra is delivered on. I think we have too much Patch Available backlog to encourage people to develop and submit patches on other versions, to find out things need to be reworked only with CI and reviews. Honestly, considering the build goes from 1 minute to 3 from what I see in the comments, I fear most people probably even use the option to skip checkstyle many times locally > Switch checkstyle running only with JDK8 to be run with JDK11 > - > > Key: CASSANDRA-18262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18262 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we run checkstyle, eclipse warnings (and probably anything else?) > only with JDK8. > In preparation to remove JDK8 we need to switch those to run with JDK11. -- 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
