[jira] [Updated] (CASSANDRA-17994) BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore
[ https://issues.apache.org/jira/browse/CASSANDRA-17994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17994: -- Change Category: Semantic Complexity: Normal Component/s: Documentation/Blog Fix Version/s: NA Status: Open (was: Triage Needed) > BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore > -- > > Key: CASSANDRA-17994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17994 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: cdays-asia-20221108-15.png > > > Blog about Cassandra Days in Hanoi, Jakarta + Singapore. > * [https://www.datastax.com/events/cassandra-day-hanoi] > * [https://www.datastax.com/events/cassandra-day-jakarta] > * [https://www.datastax.com/events/cassandra-day-singapore] > !cdays-asia-20221108-15.png|width=300! -- This message was sent by Atlassian Jira (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-17994) BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore
[ https://issues.apache.org/jira/browse/CASSANDRA-17994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17994: -- Description: Blog about Cassandra Days in Hanoi, Jakarta + Singapore. * [https://www.datastax.com/events/cassandra-day-hanoi] * [https://www.datastax.com/events/cassandra-day-jakarta] * [https://www.datastax.com/events/cassandra-day-singapore] !cdays-asia-20221108-15.png! was: Blog about Cassandra Days in Hanoi, Jakarta + Singapore. * [https://www.datastax.com/events/cassandra-day-hanoi] * [https://www.datastax.com/events/cassandra-day-jakarta] * [https://www.datastax.com/events/cassandra-day-singapore] > BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore > -- > > Key: CASSANDRA-17994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17994 > Project: Cassandra > Issue Type: Task >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Attachments: cdays-asia-20221108-15.png > > > Blog about Cassandra Days in Hanoi, Jakarta + Singapore. > * [https://www.datastax.com/events/cassandra-day-hanoi] > * [https://www.datastax.com/events/cassandra-day-jakarta] > * [https://www.datastax.com/events/cassandra-day-singapore] > !cdays-asia-20221108-15.png! -- This message was sent by Atlassian Jira (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-17994) BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore
[ https://issues.apache.org/jira/browse/CASSANDRA-17994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17994: -- Description: Blog about Cassandra Days in Hanoi, Jakarta + Singapore. * [https://www.datastax.com/events/cassandra-day-hanoi] * [https://www.datastax.com/events/cassandra-day-jakarta] * [https://www.datastax.com/events/cassandra-day-singapore] !cdays-asia-20221108-15.png|width=300! was: Blog about Cassandra Days in Hanoi, Jakarta + Singapore. * [https://www.datastax.com/events/cassandra-day-hanoi] * [https://www.datastax.com/events/cassandra-day-jakarta] * [https://www.datastax.com/events/cassandra-day-singapore] !cdays-asia-20221108-15.png! > BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore > -- > > Key: CASSANDRA-17994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17994 > Project: Cassandra > Issue Type: Task >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Attachments: cdays-asia-20221108-15.png > > > Blog about Cassandra Days in Hanoi, Jakarta + Singapore. > * [https://www.datastax.com/events/cassandra-day-hanoi] > * [https://www.datastax.com/events/cassandra-day-jakarta] > * [https://www.datastax.com/events/cassandra-day-singapore] > !cdays-asia-20221108-15.png|width=300! -- This message was sent by Atlassian Jira (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-17994) BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore
[ https://issues.apache.org/jira/browse/CASSANDRA-17994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17994: -- Attachment: cdays-asia-20221108-15.png > BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore > -- > > Key: CASSANDRA-17994 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17994 > Project: Cassandra > Issue Type: Task >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Attachments: cdays-asia-20221108-15.png > > > Blog about Cassandra Days in Hanoi, Jakarta + Singapore. > * [https://www.datastax.com/events/cassandra-day-hanoi] > * [https://www.datastax.com/events/cassandra-day-jakarta] > * [https://www.datastax.com/events/cassandra-day-singapore] > -- This message was sent by Atlassian Jira (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-17994) BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore
Erick Ramirez created CASSANDRA-17994: - Summary: BLOG - Cassandra Days Asia - Hanoi, Jakarta, Singapore Key: CASSANDRA-17994 URL: https://issues.apache.org/jira/browse/CASSANDRA-17994 Project: Cassandra Issue Type: Task Reporter: Erick Ramirez Assignee: Erick Ramirez Blog about Cassandra Days in Hanoi, Jakarta + Singapore. * [https://www.datastax.com/events/cassandra-day-hanoi] * [https://www.datastax.com/events/cassandra-day-jakarta] * [https://www.datastax.com/events/cassandra-day-singapore] -- This message was sent by Atlassian Jira (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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624196#comment-17624196 ] Berenguer Blasi commented on CASSANDRA-17987: - My God that is a lot of config file crunching! Do you have an example with repeatable tests just to doublecheck they come up ok? I remember some funnies when repeatable were added so just to be on the safe side. > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624193#comment-17624193
]
Berenguer Blasi commented on CASSANDRA-17928:
-
Yep I had tried that approach to no avail as well. I am at a loss here as
following the code, even trying to follow futures execution, etc I can't see
where the hole is...
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17993) CVE's in Cassandra 4.0.5
[ https://issues.apache.org/jira/browse/CASSANDRA-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17993: -- Resolution: Invalid Status: Resolved (was: Triage Needed) > CVE's in Cassandra 4.0.5 > > > Key: CASSANDRA-17993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17993 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Hi Team, > We request you to fix below CVE's in Cassandra 4.0.5 > > [Sonatype-2021-0234, sonatype-2019-0992, CVE-2021-37136, > sonatype-2021-0789|https://git.soma.salesforce.com/pages/Infrastructure-Security/ast.github.io/sonatype-2021-0234.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17993) CVEs in Cassandra 4.0.5
[ https://issues.apache.org/jira/browse/CASSANDRA-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17993: -- Summary: CVEs in Cassandra 4.0.5 (was: CVE's in Cassandra 4.0.5) > CVEs in Cassandra 4.0.5 > --- > > Key: CASSANDRA-17993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17993 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Hi Team, > We request you to fix below CVE's in Cassandra 4.0.5 > > [Sonatype-2021-0234, sonatype-2019-0992, CVE-2021-37136, > sonatype-2021-0789|https://git.soma.salesforce.com/pages/Infrastructure-Security/ast.github.io/sonatype-2021-0234.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17993) CVE's in Cassandra 4.0.5
[ https://issues.apache.org/jira/browse/CASSANDRA-17993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624184#comment-17624184 ] Erick Ramirez commented on CASSANDRA-17993: --- The link you provided doesn't work. Please provide details of the vulnerabilities you are reporting specifically including analysis of why you think it applies to Cassandra. Cheers! > CVE's in Cassandra 4.0.5 > > > Key: CASSANDRA-17993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17993 > Project: Cassandra > Issue Type: Bug >Reporter: Gaurav Gupta >Priority: Normal > > Hi Team, > We request you to fix below CVE's in Cassandra 4.0.5 > > [Sonatype-2021-0234, sonatype-2019-0992, CVE-2021-37136, > sonatype-2021-0789|https://git.soma.salesforce.com/pages/Infrastructure-Security/ast.github.io/sonatype-2021-0234.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16491) nodetool bootstrap resume returns success even if there is an error during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-16491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624174#comment-17624174 ] Caleb Rackliffe commented on CASSANDRA-16491: - Thanks for the patch. I've made a pass at review and left a few comments in the PR. Once we resolve that feedback, I can create a branch to run the CircleCI tests with appropriate hardware. > nodetool bootstrap resume returns success even if there is an error during > bootstrap > > > Key: CASSANDRA-16491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16491 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Caleb Rackliffe >Assignee: Leonard Ma >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > "nodetool bootstrap resume” prints a relevant error message if the operation > fails, but it then proceeds to return a normal error code. It ignores the > ProgressEventType.ERROR message that arrives before COMPLETE. This also > happens when we handle failed connections. BootstrapMonitor should at least > track whether or not it has seen an error, which would allow us to throw when > one occurs after signaling, and therefore to inform callers. > Trunk PR: [https://github.com/apache/cassandra/pull/1949] -- This message was sent by Atlassian Jira (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-17993) CVE's in Cassandra 4.0.5
Gaurav Gupta created CASSANDRA-17993: Summary: CVE's in Cassandra 4.0.5 Key: CASSANDRA-17993 URL: https://issues.apache.org/jira/browse/CASSANDRA-17993 Project: Cassandra Issue Type: Bug Reporter: Gaurav Gupta Hi Team, We request you to fix below CVE's in Cassandra 4.0.5 [Sonatype-2021-0234, sonatype-2019-0992, CVE-2021-37136, sonatype-2021-0789|https://git.soma.salesforce.com/pages/Infrastructure-Security/ast.github.io/sonatype-2021-0234.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (d754e57c -> 690823be)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit d754e57c generate docs for 9a3e5141 new 690823be generate docs for 9a3e5141 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d754e57c) \ N -- N -- N refs/heads/asf-staging (690823be) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4746956 -> 4746956 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16491) nodetool bootstrap resume returns success even if there is an error during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-16491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16491: Fix Version/s: 4.x (was: 3.0.x) (was: 3.11.x) (was: 4.0.x) > nodetool bootstrap resume returns success even if there is an error during > bootstrap > > > Key: CASSANDRA-16491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16491 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Caleb Rackliffe >Assignee: Leonard Ma >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > "nodetool bootstrap resume” prints a relevant error message if the operation > fails, but it then proceeds to return a normal error code. It ignores the > ProgressEventType.ERROR message that arrives before COMPLETE. This also > happens when we handle failed connections. BootstrapMonitor should at least > track whether or not it has seen an error, which would allow us to throw when > one occurs after signaling, and therefore to inform callers. > Trunk PR: [https://github.com/apache/cassandra/pull/1949] -- This message was sent by Atlassian Jira (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-16664) Log JVM Arguments at in-JVM Test Class Initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-16664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624153#comment-17624153
]
Caleb Rackliffe commented on CASSANDRA-16664:
-
Just made a pass at review and dropped a couple minor comments.
> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Natnael Adere
>Priority: Normal
> Labels: ghc-lhf, lhf
> Fix For: 4.0.x, 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits
> of information. The in-JVM dtest startup does not flow through
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before
> moving into executing tests.
--
This message was sent by Atlassian Jira
(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-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[
https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624121#comment-17624121
]
Erick Ramirez commented on CASSANDRA-17917:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at d754e57c generate docs for 9a3e5141
$ git push -f origin asf-site
Username for ‘https://github.com’: erickramirezau
Password for ‘https://erickramire...@github.com’:
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ 82363267...d754e57c asf-site -> asf-site (forced update)
{noformat}
The updated page is now live on the site –
https://cassandra.apache.org/_/ecosystem.html
> WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
> -
>
> Key: CASSANDRA-17917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17917
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17917-01-ecosystem.png
>
>
> This ticket is to capture the work associated with updates to the copy of
> Apache Cassandra Website's Ecosystem tool, Stargate.
> If the copy cannot be updated by October 12, 2022, please contact me or
> suggest changes in the pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (82363267 -> d754e57c)
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 82363267 generate docs for 65d5b952 add 9a3e5141 WEBSITE - Updated Stargate copy in tools section of Ecosystem page add d754e57c generate docs for 9a3e5141 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (82363267) \ N -- N -- N refs/heads/asf-site (d754e57c) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes: content/_/ecosystem.html | 2 +- .../doc/4.2/cassandra/tools/nodetool/version.html | 7 +-- .../trunk/cassandra/tools/nodetool/version.html| 7 +-- .../source/modules/ROOT/pages/ecosystem.adoc | 2 +- site-ui/build/ui-bundle.zip| Bin 4746956 -> 4746956 bytes 5 files changed, 12 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[ https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624118#comment-17624118 ] Erick Ramirez commented on CASSANDRA-17917: --- The build completed in 18 minutes and the updated page is now in staging – https://cassandra.staged.apache.org/_/ecosystem.html > WEBSITE - Update Stargate copy in the Tools section of Ecosystem page > - > > Key: CASSANDRA-17917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17917 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17917-01-ecosystem.png > > > This ticket is to capture the work associated with updates to the copy of > Apache Cassandra Website's Ecosystem tool, Stargate. > If the copy cannot be updated by October 12, 2022, please contact me or > suggest changes in the pull request. -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624111#comment-17624111 ] Ekaterina Dimitrova edited comment on CASSANDRA-17992 at 10/26/22 1:25 AM: --- [~norman] , do you think you can confirm for us the earliest netty version that supports JDK17? Or even point me in the docs if it is listed somewhere and I am missing it so I know for the next time where to look. Thanks in advance was (Author: e.dimitrova): [~norman] , do you think you can confirm for us the earliest netty version that supports JDK17? Or even point me in the docs if it is listed somewhere and I am missing so I know for the next time. Thanks in advance > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the changes between the netty > versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the changes between the netty versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the changes between versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the changes between the netty > versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Summary: Upgrade Netty on 4.x(current trunk) (was: Upgrade Netty on 4.2/5/trunk) > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the changes between the netty > versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Fix Version/s: 4.x > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the changes between the netty > versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the changes between versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the change list between versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the changes between versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.x(current trunk)
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are about 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the changes between the netty versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the changes between the netty versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] > Upgrade Netty on 4.x(current trunk) > --- > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > Fix For: 4.x > > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are about 40 versions behind in netty 4 > so I suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the changes between the netty > versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the change list between versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the change list between versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the change list between versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). For the record, we didn't see those when running CI on JDK8 and JDK11. We also need to carefully revision the change list between versions. Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). For the record, we didn't see those when running CI on JDK8 and > JDK11. We also need to carefully revision the change list between versions. > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] , [~aleksey] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > > CC [~benedict] , [~aleksey] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Description: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. CC [~benedict] was: I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. > > CC [~benedict] -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624111#comment-17624111 ] Ekaterina Dimitrova commented on CASSANDRA-17992: - [~norman] , do you think you can confirm for us the earliest netty version that supports JDK17? Or even point me in the docs if it is listed somewhere and I am missing so I know for the next time. Thanks in advance > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17992: Change Category: Operability Complexity: Normal Component/s: Dependencies Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Upgrade Netty on 4.2/5/trunk > > > Key: CASSANDRA-17992 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Priority: Low > > I haven't been able to identify from the Netty docs which was the lowest > version where JDK17 was added but we are 40 versions behind in netty 4 so I > suspect we better update. > We need to consider there was an issue with class cast exceptions when > building with JDK17 with newer versions of netty (the newest available in > March 2022). > Upgrading will cover also a fix that was discussed in > [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF > Slack thread. -- This message was sent by Atlassian Jira (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-17992) Upgrade Netty on 4.2/5/trunk
Ekaterina Dimitrova created CASSANDRA-17992: --- Summary: Upgrade Netty on 4.2/5/trunk Key: CASSANDRA-17992 URL: https://issues.apache.org/jira/browse/CASSANDRA-17992 Project: Cassandra Issue Type: Task Reporter: Ekaterina Dimitrova I haven't been able to identify from the Netty docs which was the lowest version where JDK17 was added but we are 40 versions behind in netty 4 so I suspect we better update. We need to consider there was an issue with class cast exceptions when building with JDK17 with newer versions of netty (the newest available in March 2022). Upgrading will cover also a fix that was discussed in [this|https://the-asf.slack.com/archives/CK23JSY2K/p1665567660202989] ASF Slack thread. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (82363267 -> d754e57c)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit 82363267 generate docs for 65d5b952 add 9a3e5141 WEBSITE - Updated Stargate copy in tools section of Ecosystem page new d754e57c generate docs for 9a3e5141 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (82363267) \ N -- N -- N refs/heads/asf-staging (d754e57c) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/_/ecosystem.html | 2 +- .../doc/4.2/cassandra/tools/nodetool/version.html | 7 +-- .../trunk/cassandra/tools/nodetool/version.html| 7 +-- .../source/modules/ROOT/pages/ecosystem.adoc | 2 +- site-ui/build/ui-bundle.zip| Bin 4746956 -> 4746956 bytes 5 files changed, 12 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624105#comment-17624105 ] Ekaterina Dimitrova edited comment on CASSANDRA-17987 at 10/26/22 1:13 AM: --- 3.11 looks OK to me. I haven't realized you removed the repeated jobs from UI if they haven't been set to test. That cleans the UI significantly :) 4.0 and 4.1 are the same. trunk adds also tries. They all look fine to me. It is already late, I can verify the higher resources tomorrow that nothing shifted while creating new patches. was (Author: e.dimitrova): 3.11 looks OK to me. I haven't realized you removed the repeated jobs from UI if they haven't been set to test. That cleans the UI significantly :) 4.0 and 4.1 are the same. trunk adds also tries. They all look fine to me. It is already late, I can verify the higher resources tomorrow that nothing shifted. > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624105#comment-17624105 ] Ekaterina Dimitrova commented on CASSANDRA-17987: - 3.11 looks OK to me. I haven't realized you removed the repeated jobs from UI if they haven't been set to test. That cleans the UI significantly :) 4.0 and 4.1 are the same. trunk adds also tries. They all look fine to me. It is already late, I can verify the higher resources tomorrow that nothing shifted. > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (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-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17930: Description: As discussed in this [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the Cassandra community wants to see CircleCI and ASF CI being aligned - running the same tests, configurations, all tests. A few examples of discrepancies we already noticed: * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 * dtest-large run only in Jenkins * simulator tests run only in CircleCI * In a quick skim I think I didn't see [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode * packaging is also only tested in Jenkins as far as I recall And these are only a few examples on top of my mind. I am sure we will find more. We also need to verify the way we call those tests is correct and matches in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912) Some info on our tests suites here - [https://cassandra.apache.org/_/development/testing.html,] [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our test images reside and the Jenkins build scripts, which I already referred to. CircleCI info can be found in the readme which resides in the in-tree folder dedicated to configuration and scripts for Circle CI - [https://github.com/apache/cassandra/tree/trunk/.circleci] EDIT: More findings: * burn tests missing in CircleIC * cqlshlib in 3.11. * 4.0+ we also need in-jvm JDK8 with 11, cqlshlib JDK8 with 11. was: As discussed in this [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the Cassandra community wants to see CircleCI and ASF CI being aligned - running the same tests, configurations, all tests. A few examples of discrepancies we already noticed: * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 * dtest-large run only in Jenkins * simulator tests run only in CircleCI * In a quick skim I think I didn't see [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode * packaging is also only tested in Jenkins as far as I recall And these are only a few examples on top of my mind. I am sure we will find more. We also need to verify the way we call those tests is correct and matches in both CIs. (I was looking to solve similar discrepancy in CASSANDRA-17912) Some info on our tests suites here - [https://cassandra.apache.org/_/development/testing.html,] [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our test images reside and the Jenkins build scripts, which I already referred to. CircleCI info can be found in the readme which resides in the in-tree folder dedicated to configuration and scripts for Circle CI - [https://github.com/apache/cassandra/tree/trunk/.circleci] > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicat
[jira] [Commented] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[
https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624101#comment-17624101
]
Ekaterina Dimitrova commented on CASSANDRA-17930:
-
{quote}Not a bad place for new contributors to get involved either fwiw.
{quote}
Not at all and it has a huge impact on the project.
> Ensure CircleCI and ASF Jenkins CI are aligned
> --
>
> Key: CASSANDRA-17930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17930
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
>
> As discussed in this
> [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the
> Cassandra community wants to see CircleCI and ASF CI being aligned - running
> the same tests, configurations, all tests.
> A few examples of discrepancies we already noticed:
> * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145
> * dtest-large run only in Jenkins
> * simulator tests run only in CircleCI
> * In a quick skim I think I didn't see
> [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89]
> runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode
> * packaging is also only tested in Jenkins as far as I recall
> And these are only a few examples on top of my mind. I am sure we will find
> more. We also need to verify the way we call those tests is correct and
> matches in both CIs. (I was looking to solve similar discrepancy in
> CASSANDRA-17912)
> Some info on our tests suites here -
> [https://cassandra.apache.org/_/development/testing.html,]
> [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our
> test images reside and the Jenkins build scripts, which I already referred
> to.
> CircleCI info can be found in the readme which resides in the in-tree folder
> dedicated to configuration and scripts for Circle CI -
> [https://github.com/apache/cassandra/tree/trunk/.circleci]
> EDIT: More findings:
> * burn tests missing in CircleIC
> * cqlshlib in 3.11.
> * 4.0+ we also need in-jvm JDK8 with 11, cqlshlib JDK8 with 11.
>
--
This message was sent by Atlassian Jira
(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-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624098#comment-17624098 ] Ekaterina Dimitrova commented on CASSANDRA-17930: - While looking into CASSANDRA-17987. I also noticed we will need a ticket to run also the burn tests. I will open a ticket before I forget...also cqlshlib in 3.11. 4.0+ we also need in-jvm JDK8 with 11, cqlshlib JDK8 with 11. I will add those to the ticket description. > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicated to configuration and scripts for Circle CI - > [https://github.com/apache/cassandra/tree/trunk/.circleci] > -- This message was sent by Atlassian Jira (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-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[
https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624097#comment-17624097
]
Erick Ramirez commented on CASSANDRA-17917:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#173|https://github.com/apache/cassandra-website/pull/173]|[9a3e514|https://github.com/apache/cassandra-website/commit/9a3e514118c015651e777998023e943ff75f5df1]|[#691|https://ci-cassandra.apache.org/job/cassandra-website/691/]|
> WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
> -
>
> Key: CASSANDRA-17917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17917
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17917-01-ecosystem.png
>
>
> This ticket is to capture the work associated with updates to the copy of
> Apache Cassandra Website's Ecosystem tool, Stargate.
> If the copy cannot be updated by October 12, 2022, please contact me or
> suggest changes in the pull request.
--
This message was sent by Atlassian Jira
(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-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[
https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17917:
--
Fix Version/s: NA
Source Control Link:
https://github.com/apache/cassandra-website/commit/9a3e514118c015651e777998023e943ff75f5df1
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#173|https://github.com/apache/cassandra-website/pull/173]|[9a3e514|https://github.com/apache/cassandra-website/commit/9a3e514118c015651e777998023e943ff75f5df1]|
> WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
> -
>
> Key: CASSANDRA-17917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17917
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: NA
>
> Attachments: c17917-01-ecosystem.png
>
>
> This ticket is to capture the work associated with updates to the copy of
> Apache Cassandra Website's Ecosystem tool, Stargate.
> If the copy cannot be updated by October 12, 2022, please contact me or
> suggest changes in the pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: WEBSITE - Updated Stargate copy in tools section of Ecosystem page
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 9a3e5141 WEBSITE - Updated Stargate copy in tools section of Ecosystem page 9a3e5141 is described below commit 9a3e514118c015651e777998023e943ff75f5df1 Author: Diogenese Topper AuthorDate: Wed Sep 21 23:33:47 2022 -0700 WEBSITE - Updated Stargate copy in tools section of Ecosystem page patch by Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17917 Authored by: Diogenese Topper --- site-content/source/modules/ROOT/pages/ecosystem.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site-content/source/modules/ROOT/pages/ecosystem.adoc b/site-content/source/modules/ROOT/pages/ecosystem.adoc index e5415d04..7a763b68 100644 --- a/site-content/source/modules/ROOT/pages/ecosystem.adoc +++ b/site-content/source/modules/ROOT/pages/ecosystem.adoc @@ -161,7 +161,7 @@ https://github.com/MachineAcuity/rebar[Rebar,window=blank]: Multi-tenant SaaS bo https://github.com/rickbergfalk/sqlpad[SQLPad,window=blank]: A web app for writing and running SQL queries and visualizing the results. -https://stargate.io/[Stargate,window=blank]: Open source data gateway providing CQL, Schemaless JSON Document, REST, and GraphQL APIs for Apache Cassandra. +https://stargate.io/[Stargate,window=blank]: Open source data API gateway providing REST/JSON Document API, plus CQL over gRPC, GraphQL and REST APIs. Stargate also improves Cassandra cluster and app scalability with microservice architecture. Storage, plus query coordination and API Services, are independently deployable and scalable for both APIs and native binary driver connections. https://github.com/Stratio/cassandra-lucene-index[Stratio,window=blank]: Stratio’s Cassandra Lucene Index is a plugin for Apache Cassandra that extends its index functionality to provide near real time search such as ElasticSearch or Solr, including full text search capabilities and free multivariable, geospatial and bitemporal search. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[ https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17917: -- Status: Ready to Commit (was: Review In Progress) I've staged the update locally and verified that the updates are good to go: !c17917-01-ecosystem.png|width=300! > WEBSITE - Update Stargate copy in the Tools section of Ecosystem page > - > > Key: CASSANDRA-17917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17917 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Attachments: c17917-01-ecosystem.png > > > This ticket is to capture the work associated with updates to the copy of > Apache Cassandra Website's Ecosystem tool, Stargate. > If the copy cannot be updated by October 12, 2022, please contact me or > suggest changes in the pull request. -- This message was sent by Atlassian Jira (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-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[
https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624089#comment-17624089
]
Erick Ramirez commented on CASSANDRA-17917:
---
Patch:
||Branch||PR||
|{{trunk}}|[#173|https://github.com/apache/cassandra-website/pull/173]|
> WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
> -
>
> Key: CASSANDRA-17917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17917
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Attachments: c17917-01-ecosystem.png
>
>
> This ticket is to capture the work associated with updates to the copy of
> Apache Cassandra Website's Ecosystem tool, Stargate.
> If the copy cannot be updated by October 12, 2022, please contact me or
> suggest changes in the pull request.
--
This message was sent by Atlassian Jira
(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-17917) WEBSITE - Ecosystem tool Stargate copy update
[ https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17917: -- Attachment: c17917-01-ecosystem.png > WEBSITE - Ecosystem tool Stargate copy update > - > > Key: CASSANDRA-17917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17917 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Attachments: c17917-01-ecosystem.png > > > This ticket is to capture the work associated with updates to the copy of > Apache Cassandra Website's Ecosystem tool, Stargate. > If the copy cannot be updated by October 12, 2022, please contact me or > suggest changes in the pull request. -- This message was sent by Atlassian Jira (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-17917) WEBSITE - Update Stargate copy in the Tools section of Ecosystem page
[ https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17917: -- Summary: WEBSITE - Update Stargate copy in the Tools section of Ecosystem page (was: WEBSITE - Ecosystem tool Stargate copy update) > WEBSITE - Update Stargate copy in the Tools section of Ecosystem page > - > > Key: CASSANDRA-17917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17917 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Attachments: c17917-01-ecosystem.png > > > This ticket is to capture the work associated with updates to the copy of > Apache Cassandra Website's Ecosystem tool, Stargate. > If the copy cannot be updated by October 12, 2022, please contact me or > suggest changes in the pull request. -- This message was sent by Atlassian Jira (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-17917) WEBSITE - Ecosystem tool Stargate copy update
[ https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17917: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - Ecosystem tool Stargate copy update > - > > Key: CASSANDRA-17917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17917 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the copy of > Apache Cassandra Website's Ecosystem tool, Stargate. > If the copy cannot be updated by October 12, 2022, please contact me or > suggest changes in the pull request. -- This message was sent by Atlassian Jira (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-17917) WEBSITE - Ecosystem tool Stargate copy update
[ https://issues.apache.org/jira/browse/CASSANDRA-17917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17917: - Assignee: Diogenese Topper > WEBSITE - Ecosystem tool Stargate copy update > - > > Key: CASSANDRA-17917 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17917 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > > This ticket is to capture the work associated with updates to the copy of > Apache Cassandra Website's Ecosystem tool, Stargate. > If the copy cannot be updated by October 12, 2022, please contact me or > suggest changes in the pull request. -- This message was sent by Atlassian Jira (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-17991) Possible data inconsistency during bootstrap/decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-17991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaydeepkumar Chovatia updated CASSANDRA-17991:
--
Description:
I am facing one corner case in which the deleted data resurrects.
tl;dr: This could be because when we stream all the SSTables for a given token
range to the new owner, then they are not sent atomically, so the new owner
could do compaction on the partially received SSTables, which might remove the
tombstones.
Here are the reproducible steps:
+*Prerequisite*+ # Three nodes Cassandra cluster n1, n2, and n3 (C* version
3.0.27)
#
{code:java}
CREATE KEYSPACE KS1 WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': '3'};
CREATE TABLE KS1.T1 (
key int,
c1 int,
c2 int,
c3 int
PRIMARY KEY (key)
) WITH CLUSTERING ORDER BY (key ASC)
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND gc_grace_seconds = 864000;
{code}
*Reproducible Steps*
* Day1: Insert a new record
{code:java}
INSERT INTO KS1.T1 (key, c1, c2, c3) values (1, 10, 20, 30){code}
* Day2: Other records are inserted into this table, and it goes through
multiple compactions
* Day3: Here is the data layout on SSTables on n1, n2, and n3
{code:java}
SSTable1:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable2:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
{code}
* Day4: Delete the record
{code:java}
CONSISTENCY ALL; DELETE FROM KS1.T1 WHERE key = 1; {code}
* Day5: Here is the data layout on SSTables on n1, n2, and n3
{code:java}
SSTable1:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable2:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable3 (Tombstone):
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"deletion_info" : { "marked_deleted" : "2022-10-19T00:00:00.01Z",
"local_delete_time" : "2022-10-19T00:00:00.01Z" },
"cells" : [ ]
}
{code}
* Day20: Nothing happens for more than 10 days. Let's say the data layout on
SSTables on n1, n2, and n3 is the same as Day5
* Day20: A new node (n4) joins the ring, and it is going to be responsible for
key "1". Let's say it streams the data from n3. The node _n3_ is supposed to
stream out SSTable1, SSTable2, and SSTable3, but it does not happen atomically
as per the streaming algorithm. Let's consider a scenario in that _n4_ receives
SSTable1 and SSTable3, but not yet SSTable2, and _n4_ compacts SSTable1 and
SSTable3. In this case, _n4_ would purge the key "1". So at this time, there
are no traces of key "1" on {_}n4{_}. After some time, SSTable2 is streamed,
and at this time it will stream the key "1" as well.
* Day20: _n4_ becomes normal
{code:java}
Query on n4:
$> CONSISTENCY LOCAL_ONE; SELECT * FROM KS1.T1 WHERE key = 1;
// 1 | 10 | 20 | 30 <-- A record is returned
Query on n1:
$> CONSISTENCY LOCAL_ONE; SELECT * FROM KS1.T1 WHERE key = 1;
// //no output{code}
Does this make sense?
*Possible Solution*
* One of the solutions is to maybe not purge tombstones while there are token
range movements in the ring
was:
I am facing one corner case in which the deleted data resurrects.
tl;dr: This could be because when we stream all the SSTables for a given token
range to the new owner, then they are not sent atomically, so the new owner
could do compaction on the partially received SSTables, which might remove the
tombstones.
Here are the reproducible s
[jira] [Updated] (CASSANDRA-17991) Possible data inconsistency during bootstrap/decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-17991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaydeepkumar Chovatia updated CASSANDRA-17991:
--
Description:
I am facing one corner case in which the deleted data resurrects.
tl;dr: This could be because when we stream all the SSTables for a given token
range to the new owner, then they are not sent atomically, so the new owner
could do compaction on the partially received SSTables, which might remove the
tombstones.
Here are the reproducible steps:
+*Prerequisite*+ # Three nodes Cassandra cluster n1, n2, and n3 (C* version
3.0.27)
#
{code:java}
CREATE KEYSPACE KS1 WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': '3'};
CREATE TABLE KS1.T1 (
key int,
c1 int,
c2 int,
c3 int
PRIMARY KEY (key)
) WITH CLUSTERING ORDER BY (key ASC)
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND gc_grace_seconds = 864000;
{code}
*Reproducible Steps*
* Day1: Insert a new record
{code:java}
INSERT INTO KS1.T1 (key, c1, c2, c3) values (1, 10, 20, 30){code}
* Day2: Other records are inserted into this table, and it goes through
multiple compactions
* Day3: Here is the data layout on SSTables on n1, n2, and n3
{code:java}
SSTable1:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable2:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
{code}
* Day4: Delete the record
{code:java}
CONSISTENCY ALL; DELETE FROM KS1.T1 WHERE key = 1; {code}
* Day5: Here is the data layout on SSTables on n1, n2, and n3
{code:java}
SSTable1:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable2:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable3 (Tombstone):
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"deletion_info" : { "marked_deleted" : "2022-10-19T00:00:00.01Z",
"local_delete_time" : "2022-10-19T00:00:00.01Z" },
"cells" : [ ]
}
{code}
* Day20: Nothing happens for more than 10 days. Let's say the data layout on
SSTables on n1, n2, and n3 is the same as Day5
* Day20: A new node (n4) joins the ring, and it is going to be responsible for
key "1". Let's say it streams the data from n3. The node _n3_ is supposed to
stream out SSTable1, SSTable2, and SSTable3, but it does not happen atomically
as per the streaming algorithm. Let's consider a scenario in that _n4_ receives
SSTable1 and SSTable3, but not yet SSTable2, and _n4_ compacts SSTable1 and
SSTable3. In this case, _n4_ would purge the key "1". So at this time, there
are no traces of key "1" on {_}n4{_}. After some time, SSTable2 is streamed,
and at this time it will stream the key "1" as well.
* Day20: _n4_ becomes normal
{code:java}
Query on n4:
$> CONSISTENCY LOCAL_ONE; SELECT * FROM KS1.T1 WHERE key = 1;
// 1 | 10 | 20 | 30 <-- A record is returned
Query on n1:
$> CONSISTENCY LOCAL_ONE; SELECT * FROM KS1.T1 WHERE key = 1;
// //no output{code}
Does this make sense?{*}{{*}}
*Possible Solution*
* One of the solutions is to maybe not purge tombstones while there are token
range movements in the ring
was:
I am facing one corner case in which the deleted data resurrects.
tl;dr: This could be because when we stream all the SSTables for a given token
range to the new owner, then they are not sent atomically, so the new owner
could do compaction on the partially received SSTables, which might remove the
tombstones.
Here are the repro
[jira] [Created] (CASSANDRA-17991) Possible data inconsistency during bootstrap/decommission
Jaydeepkumar Chovatia created CASSANDRA-17991:
-
Summary: Possible data inconsistency during bootstrap/decommission
Key: CASSANDRA-17991
URL: https://issues.apache.org/jira/browse/CASSANDRA-17991
Project: Cassandra
Issue Type: Bug
Components: Consistency/Bootstrap and Decommission
Reporter: Jaydeepkumar Chovatia
I am facing one corner case in which the deleted data resurrects.
tl;dr: This could be because when we stream all the SSTables for a given token
range to the new owner, then they are not sent atomically, so the new owner
could do compaction on the partially received SSTables, which might remove the
tombstones.
Here are the reproducible steps:
+*Prerequisite*+ # Three nodes Cassandra cluster n1, n2, and n3
#
{code:java}
CREATE KEYSPACE KS1 WITH replication = {'class': 'NetworkTopologyStrategy',
'dc1': '3'};
CREATE TABLE KS1.T1 (
key int,
c1 int,
c2 int,
c3 int
PRIMARY KEY (key)
) WITH CLUSTERING ORDER BY (key ASC)
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND gc_grace_seconds = 864000;
{code}
*Reproducible Steps*
* Day1: Insert a new record
{code:java}
INSERT INTO KS1.T1 (key, c1, c2, c3) values (1, 10, 20, 30){code}
* Day2: Other records are inserted into this table, and it goes through
multiple compactions
* Day3: Here is the data layout on SSTables on n1, n2, and n3
{code:java}
SSTable1:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable2:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
{code}
* Day4: Delete the record
{code:java}
CONSISTENCY ALL; DELETE FROM KS1.T1 WHERE key = 1; {code}
* Day5: Here is the data layout on SSTables on n1, n2, and n3
{code:java}
SSTable1:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable2:
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"liveness_info" : { "tstamp" : "2022-10-15T00:00:00.01Z"},
"cells" : [
{ "name" : "c1", "value" : 10 },
{ "name" : "c2", "value" : 20 },
{ "name" : "c3", "value" : 30 },
]
}
.
SSTable3 (Tombstone):
{
"partition" : {
"key" : [ "1" ],
"position" : 900
},
"rows" : [
"type" : "row",
"position" : 10,
"deletion_info" : { "marked_deleted" : "2022-10-19T00:00:00.01Z",
"local_delete_time" : "2022-10-19T00:00:00.01Z" },
"cells" : [ ]
}
{code}
* Day20: Nothing happens for more than 10 days. Let's say the data layout on
SSTables on n1, n2, and n3 is the same as Day5
* Day20: A new node (n4) joins the ring, and it is going to be responsible for
key "1". Let's say it streams the data from n3. The node _n3_ is supposed to
stream out SSTable1, SSTable2, and SSTable3, but it does not happen atomically
as per the streaming algorithm. Let's consider a scenario in that _n4_ receives
SSTable1 and SSTable3, but not yet SSTable2, and _n4_ compacts SSTable1 and
SSTable3. In this case, _n4_ would purge the key "1". So at this time, there
are no traces of key "1" on {_}n4{_}. After some time, SSTable2 is streamed,
and at this time it will stream the key "1" as well.
* Day20: _n4_ becomes normal
{code:java}
Query on n4:
$> CONSISTENCY LOCAL_ONE; SELECT * FROM KS1.T1 WHERE key = 1;
// 1 | 10 | 20 | 30 <-- A record is returned
Query on n1:
$> CONSISTENCY LOCAL_ONE; SELECT * FROM KS1.T1 WHERE key = 1;
// //no output{code}
Does this make sense?{*}{*}
*Possible Solution*
* One of the solutions is to maybe not purge tombstones while there are token
range movements in the ring
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail
[jira] [Updated] (CASSANDRA-17934) Add --resolve-ip option on 'nodetool gossipinfo'
[ https://issues.apache.org/jira/browse/CASSANDRA-17934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17934: Reviewers: Caleb Rackliffe, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Needs Committer) > Add --resolve-ip option on 'nodetool gossipinfo' > > > Key: CASSANDRA-17934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17934 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Paulo Motta >Assignee: Maxim Chanturiay >Priority: Normal > Labels: lhf > Fix For: 4.1-rc, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Give nodetool gossipinfo the option of either displaying IPs or hostnames for > the nodes in a ring. > Note: this option is already present for "nodetool status" and "nodetool ring" -- This message was sent by Atlassian Jira (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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17987: Reviewers: Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17753: -- Source Control Link: https://github.com/apache/cassandra/commit/230fe8e64722ac02dbf8cdafb7d4fef120726dd7 (was: https://github.com/apache/cassandra/pull/1729) Resolution: Fixed Status: Resolved (was: Ready to Commit) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.2 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian 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: Include Git SHA in --verbose flag for nodetool version
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 230fe8e647 Include Git SHA in --verbose flag for nodetool version
230fe8e647 is described below
commit 230fe8e64722ac02dbf8cdafb7d4fef120726dd7
Author: Abe Ratnofsky
AuthorDate: Fri Feb 4 11:15:42 2022 -0800
Include Git SHA in --verbose flag for nodetool version
Patch by Abe Ratnofsky; review by Brandon Williams, Caleb Rackliffe,
Michael Semb Wever and Stefan Miklosovic for CASSANDRA-17753
---
.build/build-git.xml | 54 ++
CHANGES.txt| 1 +
build.xml | 7 ++-
conf/cassandra.yaml| 1 +
.../apache/cassandra/service/StorageService.java | 7 +++
.../cassandra/service/StorageServiceMBean.java | 6 +++
src/java/org/apache/cassandra/tools/NodeProbe.java | 5 ++
.../apache/cassandra/tools/nodetool/Version.java | 9 +++-
.../org/apache/cassandra/utils/FBUtilities.java| 25 --
.../cassandra/distributed/test/NodeToolTest.java | 14 ++
10 files changed, 122 insertions(+), 7 deletions(-)
diff --git a/.build/build-git.xml b/.build/build-git.xml
new file mode 100644
index 00..03b5ca7f5b
--- /dev/null
+++ b/.build/build-git.xml
@@ -0,0 +1,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+git.sha=${git.sha}
+
+
+
+
+
+
+
+
+
+Repository state is
dirty
+${git.diffstat}
+
+
diff --git a/CHANGES.txt b/CHANGES.txt
index a51b81d926..5a4dcba477 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Include Git SHA in --verbose flag for nodetool version (CASSANDRA-17753)
* Update Byteman to 4.0.20 and Jacoco to 0.8.8 (CASSANDRA-16413)
* Add memtable option among possible tab completions for a table
(CASSANDRA-17982)
* Adds a trie-based memtable implementation (CASSANDRA-17240)
diff --git a/build.xml b/build.xml
index 88ffc8836b..ffb107c7b1 100644
--- a/build.xml
+++ b/build.xml
@@ -438,11 +438,12 @@
-
+
+
@@ -485,7 +486,7 @@
-
@@ -695,6 +696,7 @@
+
@@ -1972,4 +1974,5 @@
+
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 93a581b058..17c994bbb1 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1881,3 +1881,4 @@ drop_compact_storage_enabled: false
#heartbeat_file: /var/lib/cassandra/data/cassandra-heartbeat
#excluded_keyspaces: # comma separated list of keyspaces to exclude from
the check
#excluded_tables: # comma separated list of keyspace.table pairs to
exclude from the check
+
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 1d0ccc0866..b4022ba8a7 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -788,6 +788,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
public synchronized void initServer(int schemaTimeoutMillis, int
ringTimeoutMillis) throws ConfigurationException
{
logger.info("Cassandra version: {}",
FBUtilities.getReleaseVersionString());
+logger.info("Git SHA: {}", FBUtilities.getGitSHA());
logger.info("CQL version: {}", QueryProcessor.CQL_VERSION);
logger.info("Native protocol supported versions: {} (default: {})",
StringUtils.join(ProtocolVersion.supportedVersions(), ",
"), ProtocolVersion.CURRENT);
@@ -3659,6 +3660,12 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
return FBUtilities.getReleaseVersionString();
}
+@Override
+public String getGitSHA()
+{
+return FBUtilities.getGitSHA();
+}
+
public String getSchemaVersion()
{
return Schema.instance.getVersion().toString();
diff --git a/src/java/org/apache/cassandra/service/StorageServiceMBean.java
b/src/java/org/apache/cassandra/service/StorageServiceMBean.java
index da77fcf286..101c9a3ebf 100644
--- a/src/java/org/apache/cassandra/service/StorageServiceMBean.java
+++ b/src/java/org/apache/cassandra/service/StorageServiceMBean.java
@@ -102,6 +102,12 @@ public interface StorageServiceMBean extends
NotificationEmitter
*/
public String getReleaseVersion()
[jira] [Updated] (CASSANDRA-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17753: -- Fix Version/s: 4.2 (was: 4.x) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.2 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17753: -- Status: Ready to Commit (was: Review In Progress) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17753: -- Status: Review In Progress (was: Needs Committer) > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623997#comment-17623997 ] Stefan Miklosovic commented on CASSANDRA-17753: --- [~maedhroz] I will commit soon. > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17240) CEP-19: Trie memtable implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623987#comment-17623987
]
Alex Petrov edited comment on CASSANDRA-17240 at 10/25/22 7:07 PM:
---
{quote}I don't think that we should default to consider experimental everything
that hasn't been tested with Harry, nor consider production-ready everything
that has been tested with it
{quote}
[~adelapena] I agree about the second part (ie not considering something
production ready if it has been tested with Harry), but former I tend to
disagree with. I realise there might be no desire to adopt Harry by either you
personally or by members of your team, but Harry has proven itself to find bugs
other testing approaches do not, and it models Cassandra behaviour in a way
that can reasonably only be matched by handcrafting a very large number of test
cases, which is of course impossible. Unless you can provide an example of an
integration testing tool that can match Harry in an ability to validate a
feature, I'll be happy to check it out and compare approaches.
If I'm not mistaken, there is no publicly available tooling that was used to
validate _correctness_ of Cassandra as a whole with trie memtables enabled. I
realize there might be some internal tooling you might have used for
verification, but unless this tooling is available for others to build
confidence and reproduce results, I'm afraid this is not enough, either.
Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also
agreed that we should not make this feature GA until we've exhaustively tested
it with Harry.
{quote}seen some real usage
{quote}
I do not think that "some" real usage is a good measure by any means. We're
testing small, large instances, multitude of schemas, short- and long running
tests. Database should work for every use-case that can be thought of, not for
some specific use-case, and tooling around verification should strive to cover
all of those cases, especially for cases as crucial as this one.
I think with 4.0 release, we've been able to prove that fuzz testing is the
only way to build confidence, since smaller and targeted use-cases often
exercise only a fraction of our code.
{quote}trying to force developers to use Harry if they want to move their
features out of the experimental status
{quote}
I do not see why not. If additions to Paxos aren't going to be tested with a
simulator, I don't think anyone would feel safe to use them. Similarly, we do
have a strong preference (even though not a general rule) for in-jvm dtests
over python dtests. All of these tools didn't exist until very recently.
I would not go as far as "forcing" anyone to use Harry. I think it's best to
let people make wise decisions based on the data available. But unless there's
at least you can demonstrate that at least an equivalent rigour was applied to
testing, someone will just have to run Harry tests. And I think both Caleb and
myself have been not only advocating for, but also actively offering help for
testing both SAI and trie-based indexes with Harry.
With recent additions, running Harry will be not any harder to run then
{{{}stress{}}}. You specify schema, specify number of rows, and specify the
mode (read or write). There are more sophisticated modes of running and many
more tunables that you may exercise, but that's kind of a bare minimum. I'm
using it for my development all the time, and it is proving itself useful every
day.
was (Author: ifesdjeen):
{quote}I don't think that we should default to consider experimental everything
that hasn't been tested with Harry, nor consider production-ready everything
that has been tested with it
{quote}
[~adelapena] I agree about the second part (ie not considering something
production ready if it has been tested with Harry), but former I tend to
disagree with. I realise there might be no desire to adopt Harry by either you
personally or by members of your team, but Harry has proven itself to find bugs
other testing approaches do not, and it models Cassandra behaviour in a way
that can reasonably only be matched by handcrafting a very large number of test
cases, which is of course impossible. Unless you can provide an example of an
integration testing tool that can match Harry in an ability to validate a
feature, I'll be happy to check it out and compare approaches.
If I'm not mistaken, there is no publicly available tooling that was used to
validate _correctness_ of Cassandra as a whole with trie memtables enabled. I
realize there might be some internal tooling you might have used for
verification, but unless this tooling is available for others to build
confidence and reproduce results, I'm afraid this is not enough, either.
Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also
agreed that
[jira] [Comment Edited] (CASSANDRA-17240) CEP-19: Trie memtable implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623988#comment-17623988
]
David Capwell edited comment on CASSANDRA-17240 at 10/25/22 7:04 PM:
-
Been talking in Slack, moving context here.
The config side of this patch is problematic, the table param depends on a
local yaml being consistent (at least the name) cross the cluster, but our
schema logic doesn't actually allow this which then causes a schema mismatch
cross the cluster... This will also cause the conflicting nodes to fail to
re-boot (guess a slight positive?)...
I strongly feel that we shouldn't depend on the config if we are adding a table
param, the table param should be self contained similar to
compression/compaction; we should do something like this
{code}
WITH memtable = {'type': 'trie', 'shards': 42}
{code}
Now, this also gets to the question, what do you do if a node doesn't
understand the type? Simple example is rolling upgrades picking up a new
implementation or custom one... in this case we should revert back to the
default (coordinator should attempt to validate and reject unknown, rest should
fall back).
Second comment is the yaml is very dense and hard to use, we could simplify by
making it strongly typed; we should move away from
{code}
memtable:
configurations:
node1:
class_name: TrieMemtable
parameters:
shards: 42
{code}
To
{code}
memtable:
type: TrieMemtable # or "trie", cool with alias or explicit
shards: 42
{code}
If we want to override at the table level we could also add a
{code}
memtable_table_overrides:
ks.table: # or how/ever we wish to call out the name
type: trie
shards: 4
ks: # override at the key space level
type: skiplist
{code}
was (Author: dcapwell):
Been talking in Slack, moving context here.
The config side of this patch is problematic, the table param depends on a
local yaml being consistent (at least the name) cross the cluster, but our
schema logic doesn't actually allow this which then causes a schema mismatch
cross the cluster... This will also cause the conflicting nodes to fail to
re-boot (guess a slight positive?)...
I strongly feel that we shouldn't depend on the config if we are adding a table
param, the table param should be self contained similar to
compression/compaction; we should do something like this
{code}
WITH memtable = {'type': 'trie', 'shards': 42}
{code}
Now, this also gets to the question, what do you do if a node doesn't
understand the type? Simple example is rolling upgrades picking up a new
implementation or custom one... in this case we should revert back to the
default (coordinator should attempt to validate and reject unknown, rest should
fall back).
Second comment is the yaml is very dense and hard to use, we could simplify by
making it strongly typed; we should move away from
{code}
memtable:
configurations:
node1:
class_name: TrieMemtable
parameters:
shards: 42
{code}
To
{code}
memtable:
type: TrieMemtable # or "trie", cool with alias or explicit
shards: 42
{code}
If we want to override at the table level we could also add a
{code}
memtable_table_overrides:
ks.table: # or how/ever we wish to call out the name
type: trie
shards: 4
ks: # override at the key space level
type: skiplist
shards:
{code}
> CEP-19: Trie memtable implementation
>
>
> Key: CASSANDRA-17240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17240
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 4.2
>
> Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png,
> density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png,
> latency-9_1-95.png, throughput_SG.png, throughput_apache.png
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Trie-based memtable implementation as described in CEP-19, built on top of
> CASSANDRA-17034 and CASSANDRA-6936.
> The implementation is available in this
> [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240].
--
This message was sent by Atlassian Jira
(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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623990#comment-17623990
]
Ekaterina Dimitrova commented on CASSANDRA-17928:
-
That might explain why I hit it easier in 4.1 than 4.0 :(
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17240) CEP-19: Trie memtable implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623988#comment-17623988
]
David Capwell edited comment on CASSANDRA-17240 at 10/25/22 7:02 PM:
-
Been talking in Slack, moving context here.
The config side of this patch is problematic, the table param depends on a
local yaml being consistent (at least the name) cross the cluster, but our
schema logic doesn't actually allow this which then causes a schema mismatch
cross the cluster... This will also cause the conflicting nodes to fail to
re-boot (guess a slight positive?)...
I strongly feel that we shouldn't depend on the config if we are adding a table
param, the table param should be self contained similar to
compression/compaction; we should do something like this
{code}
WITH memtable = {'type': 'trie', 'shards': 42}
{code}
Now, this also gets to the question, what do you do if a node doesn't
understand the type? Simple example is rolling upgrades picking up a new
implementation or custom one... in this case we should revert back to the
default (coordinator should attempt to validate and reject unknown, rest should
fall back).
Second comment is the yaml is very dense and hard to use, we could simplify by
making it strongly typed; we should move away from
{code}
memtable:
configurations:
node1:
class_name: TrieMemtable
parameters:
shards: 42
{code}
To
{code}
memtable:
type: TrieMemtable # or "trie", cool with alias or explicit
shards: 42
{code}
If we want to override at the table level we could also add a
{code}
memtable_table_overrides:
ks.table: # or how/ever we wish to call out the name
type: trie
shards: 4
ks: # override at the key space level
type: skiplist
shards:
{code}
was (Author: dcapwell):
Been talking in Slack, moving context here.
The config side of this patch is problematic, the table param depends on a
local yaml being consistent (at least the name) cross the cluster, but our
schema logic doesn't actually allow this which then causes a schema mismatch
cross the cluster... This will also cause the conflicting nodes to fail to
re-boot (guess a slight positive?)...
I strongly feel that we shouldn't depend on the config if we are adding a table
param, the table param should be self contained similar to
compression/compaction; we should do something like this
{code}
WITH memtable = {'type': 'trie', 'shards': 42}
{code}
Now, this also gets to the question, what do you do if a node doesn't
understand the type? Simple example is rolling upgrades picking up a new
implementation or custom one... in this case we should revert back to the
default (coordinator should attempt to validate and reject unknown, rest should
fall back).
Second comment is the yaml is very dense and hard to use, we could simplify by
making it strongly typed; we should move away from
{code}
memtable:
configurations:
node1:
class_name: TrieMemtable
parameters:
shards: 42
{code}
To
{code}
memtable:
type: TrieMemtable # or "trie", cool with alias or explicit
shards: 42
{code}
If we want to override at the table level we could also add a
{code}
memtable_table_overrides:
ks.table: # or how/ever we wish to call out the name
type: trie
shards: 4
{code}
> CEP-19: Trie memtable implementation
>
>
> Key: CASSANDRA-17240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17240
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 4.2
>
> Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png,
> density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png,
> latency-9_1-95.png, throughput_SG.png, throughput_apache.png
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Trie-based memtable implementation as described in CEP-19, built on top of
> CASSANDRA-17034 and CASSANDRA-6936.
> The implementation is available in this
> [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240].
--
This message was sent by Atlassian Jira
(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-17240) CEP-19: Trie memtable implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623988#comment-17623988
]
David Capwell commented on CASSANDRA-17240:
---
Been talking in Slack, moving context here.
The config side of this patch is problematic, the table param depends on a
local yaml being consistent (at least the name) cross the cluster, but our
schema logic doesn't actually allow this which then causes a schema mismatch
cross the cluster... This will also cause the conflicting nodes to fail to
re-boot (guess a slight positive?)...
I strongly feel that we shouldn't depend on the config if we are adding a table
param, the table param should be self contained similar to
compression/compaction; we should do something like this
{code}
WITH memtable = {'type': 'trie', 'shards': 42}
{code}
Now, this also gets to the question, what do you do if a node doesn't
understand the type? Simple example is rolling upgrades picking up a new
implementation or custom one... in this case we should revert back to the
default (coordinator should attempt to validate and reject unknown, rest should
fall back).
Second comment is the yaml is very dense and hard to use, we could simplify by
making it strongly typed; we should move away from
{code}
memtable:
configurations:
node1:
class_name: TrieMemtable
parameters:
shards: 42
{code}
To
{code}
memtable:
type: TrieMemtable # or "trie", cool with alias or explicit
shards: 42
{code}
If we want to override at the table level we could also add a
{code}
memtable_table_overrides:
ks.table: # or how/ever we wish to call out the name
type: trie
shards: 4
{code}
> CEP-19: Trie memtable implementation
>
>
> Key: CASSANDRA-17240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17240
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Fix For: 4.2
>
> Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png,
> density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png,
> latency-9_1-95.png, throughput_SG.png, throughput_apache.png
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Trie-based memtable implementation as described in CEP-19, built on top of
> CASSANDRA-17034 and CASSANDRA-6936.
> The implementation is available in this
> [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240].
--
This message was sent by Atlassian Jira
(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-17240) CEP-19: Trie memtable implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623987#comment-17623987
]
Alex Petrov edited comment on CASSANDRA-17240 at 10/25/22 6:58 PM:
---
{quote}I don't think that we should default to consider experimental everything
that hasn't been tested with Harry, nor consider production-ready everything
that has been tested with it
{quote}
[~adelapena] I agree about the second part (ie not considering something
production ready if it has been tested with Harry), but former I tend to
disagree with. I realise there might be no desire to adopt Harry by either you
personally or by members of your team, but Harry has proven itself to find bugs
other testing approaches do not, and it models Cassandra behaviour in a way
that can reasonably only be matched by handcrafting a very large number of test
cases, which is of course impossible. Unless you can provide an example of an
integration testing tool that can match Harry in an ability to validate a
feature, I'll be happy to check it out and compare approaches.
If I'm not mistaken, there is no publicly available tooling that was used to
validate _correctness_ of Cassandra as a whole with trie memtables enabled. I
realize there might be some internal tooling you might have used for
verification, but unless this tooling is available for others to build
confidence and reproduce results, I'm afraid this is not enough, either.
Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also
agreed that we should not make this feature GA until we've exhaustively tested
it with Harry.
{quote}seen some real usage
{quote}
I do not think that "some" real usage is a good measure by any means. We're
testing small, large instances, multitude of schemas, short- and long running
tests. Database should work for every use-case that can be thought of, not for
some specific use-case, and tooling around verification should strive to cover
all of those cases, especially for cases as crucial as this one.
I think with 4.0 release, we've been able to prove that fuzz testing is the
only way to build confidence, since smaller and targeted use-cases often
exercise only a fraction of our code.
bq. trying to force developers to use Harry if they want to move their features
out of the experimental status
I do not see why not. If additions to Paxos aren't going to be tested with a
simulator, I don't think anyone would feel safe to use them. Similarly, we do
have a strong preference (even though not a general rule) for in-jvm dtests
over python dtests. All of these tools didn't exist until very recently.
I would not go as far as "forcing" anyone to use Harry. I think it's best to
let people make wise decisions based on the data available. But unless there's
at least you can demonstrate that at least an equivalent rigour was applied to
testing, someone will just have to run Harry tests. And I think both Caleb and
myself have been not only advocating for, but also actively offering help for
testing both SAI and trie-based indexes with Harry.
was (Author: ifesdjeen):
bq. I don't think that we should default to consider experimental everything
that hasn't been tested with Harry, nor consider production-ready everything
that has been tested with it
[~adelapena] I agree about the second part (ie not considering something
production ready if it has been tested with Harry), but former I tend to
disagree with. I realise there might be no desire to adopt Harry by either you
personally or by members of your team, but Harry has proven itself to find bugs
other testing approaches do not, and it models Cassandra behaviour in a way
that can reasonably only be matched by handcrafting a very large number of test
cases, which is of course impossible. Unless you can provide an example of an
integration testing tool that can match Harry in an ability to validate a
feature, I'll be happy to check it out and compare approaches.
If I'm not mistaken, there is no publicly available tooling that was used to
validate _correctness_ of Cassandra as a whole with trie memtables enabled. I
realize there might be some internal tooling you might have used for
verification, but unless this tooling is available for others to build
confidence and reproduce results, I'm afraid this is not enough, either.
Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also
agreed that we should not make this feature GA until we've exhaustively tested
it with Harry.
bq. seen some real usage
I do not think that "some" real usage is a good measure by any means. We're
testing small, large instances, multitude of schemas, short- and long running
tests. Database should work for every use-case that can be thought of, not for
some specific use-case, and tooling around verification should s
[jira] [Comment Edited] (CASSANDRA-17240) CEP-19: Trie memtable implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623987#comment-17623987 ] Alex Petrov edited comment on CASSANDRA-17240 at 10/25/22 6:53 PM: --- bq. I don't think that we should default to consider experimental everything that hasn't been tested with Harry, nor consider production-ready everything that has been tested with it [~adelapena] I agree about the second part (ie not considering something production ready if it has been tested with Harry), but former I tend to disagree with. I realise there might be no desire to adopt Harry by either you personally or by members of your team, but Harry has proven itself to find bugs other testing approaches do not, and it models Cassandra behaviour in a way that can reasonably only be matched by handcrafting a very large number of test cases, which is of course impossible. Unless you can provide an example of an integration testing tool that can match Harry in an ability to validate a feature, I'll be happy to check it out and compare approaches. If I'm not mistaken, there is no publicly available tooling that was used to validate _correctness_ of Cassandra as a whole with trie memtables enabled. I realize there might be some internal tooling you might have used for verification, but unless this tooling is available for others to build confidence and reproduce results, I'm afraid this is not enough, either. Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also agreed that we should not make this feature GA until we've exhaustively tested it with Harry. bq. seen some real usage I do not think that "some" real usage is a good measure by any means. We're testing small, large instances, multitude of schemas, short- and long running tests. Database should work for every use-case that can be thought of, not for some specific use-case, and tooling around verification should strive to cover all of those cases, especially for cases as crucial as this one. I think with 4.0 release, we've been able to prove that fuzz testing is the only way to build confidence, since smaller and targeted use-cases often exercise only a fraction of our code. was (Author: ifesdjeen): > I don't think that we should default to consider experimental everything that > hasn't been tested with Harry, nor consider production-ready everything that > has been tested with it [~adelapena] I agree about the second part (ie not considering something production ready if it has been tested with Harry), but former I tend to disagree with. I realise there might be no desire to adopt Harry by either you personally or by members of your team, but Harry has proven itself to find bugs other testing approaches do not, and it models Cassandra behaviour in a way that can reasonably only be matched by handcrafting a very large number of test cases, which is of course impossible. Unless you can provide an example of an integration testing tool that can match Harry in an ability to validate a feature, I'll be happy to check it out and compare approaches. If I'm not mistaken, there is no publicly available tooling that was used to validate _correctness_ of Cassandra as a whole with trie memtables enabled. I realize there might be some internal tooling you might have used for verification, but unless this tooling is available for others to build confidence and reproduce results, I'm afraid this is not enough, either. Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also agreed that we should not make this feature GA until we've exhaustively tested it with Harry. > CEP-19: Trie memtable implementation > > > Key: CASSANDRA-17240 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17240 > Project: Cassandra > Issue Type: Improvement > Components: Local/Memtable >Reporter: Branimir Lambov >Assignee: Branimir Lambov >Priority: Normal > Fix For: 4.2 > > Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png, > density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png, > latency-9_1-95.png, throughput_SG.png, throughput_apache.png > > Time Spent: 13.5h > Remaining Estimate: 0h > > Trie-based memtable implementation as described in CEP-19, built on top of > CASSANDRA-17034 and CASSANDRA-6936. > The implementation is available in this > [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240]. -- This message was sent by Atlassian Jira (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-17240) CEP-19: Trie memtable implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623987#comment-17623987 ] Alex Petrov commented on CASSANDRA-17240: - > I don't think that we should default to consider experimental everything that > hasn't been tested with Harry, nor consider production-ready everything that > has been tested with it [~adelapena] I agree about the second part (ie not considering something production ready if it has been tested with Harry), but former I tend to disagree with. I realise there might be no desire to adopt Harry by either you personally or by members of your team, but Harry has proven itself to find bugs other testing approaches do not, and it models Cassandra behaviour in a way that can reasonably only be matched by handcrafting a very large number of test cases, which is of course impossible. Unless you can provide an example of an integration testing tool that can match Harry in an ability to validate a feature, I'll be happy to check it out and compare approaches. If I'm not mistaken, there is no publicly available tooling that was used to validate _correctness_ of Cassandra as a whole with trie memtables enabled. I realize there might be some internal tooling you might have used for verification, but unless this tooling is available for others to build confidence and reproduce results, I'm afraid this is not enough, either. Lastly, we had a discussion with [~blambov] during ApacheCon, and he has also agreed that we should not make this feature GA until we've exhaustively tested it with Harry. > CEP-19: Trie memtable implementation > > > Key: CASSANDRA-17240 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17240 > Project: Cassandra > Issue Type: Improvement > Components: Local/Memtable >Reporter: Branimir Lambov >Assignee: Branimir Lambov >Priority: Normal > Fix For: 4.2 > > Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png, > density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png, > latency-9_1-95.png, throughput_SG.png, throughput_apache.png > > Time Spent: 13.5h > Remaining Estimate: 0h > > Trie-based memtable implementation as described in CEP-19, built on top of > CASSANDRA-17034 and CASSANDRA-6936. > The implementation is available in this > [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240]. -- This message was sent by Atlassian Jira (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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623983#comment-17623983
]
Brandon Williams commented on CASSANDRA-17928:
--
bq. The run for 4.0 also hits a failure, but this time not a NPE but an
assertion error, probably due to a slow run
Incidentally the await patch should solve this, but we're still left with the
mysterious NPE in 4.1.
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623981#comment-17623981
]
Andres de la Peña commented on CASSANDRA-17928:
---
The run for 4.0 also hits a failure, but this time not a NPE but an assertion
error, probably due to a slow run:
https://app.circleci.com/pipelines/github/driftx/cassandra/682/workflows/69d0d7ac-52bc-4f81-b7cd-fdfe7a75c2b7/jobs/7508/tests
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16491) nodetool bootstrap resume returns success even if there is an error during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-16491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16491: Reviewers: Caleb Rackliffe, Caleb Rackliffe Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > nodetool bootstrap resume returns success even if there is an error during > bootstrap > > > Key: CASSANDRA-16491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16491 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Caleb Rackliffe >Assignee: Leonard Ma >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > > "nodetool bootstrap resume” prints a relevant error message if the operation > fails, but it then proceeds to return a normal error code. It ignores the > ProgressEventType.ERROR message that arrives before COMPLETE. This also > happens when we handle failed connections. BootstrapMonitor should at least > track whether or not it has seen an error, which would allow us to throw when > one occurs after signaling, and therefore to inform callers. > Trunk PR: [https://github.com/apache/cassandra/pull/1949] -- This message was sent by Atlassian Jira (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-16664) Log JVM Arguments at in-JVM Test Class Initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-16664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16664:
Reviewers: Caleb Rackliffe, David Capwell (was: David Capwell)
> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Natnael Adere
>Priority: Normal
> Labels: ghc-lhf, lhf
> Fix For: 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits
> of information. The in-JVM dtest startup does not flow through
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before
> moving into executing tests.
--
This message was sent by Atlassian Jira
(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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623947#comment-17623947
]
Andres de la Peña commented on CASSANDRA-17928:
---
It seems that the run for 4.1 has hit a NPE:
https://app.circleci.com/pipelines/github/adelapena/cassandra/2328/workflows/50f33d9b-c7c6-4aa9-bac9-22ac78ad6b8c/jobs/23224
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623929#comment-17623929 ] Abe Ratnofsky commented on CASSANDRA-17753: --- [~smiklosovic] thanks for taking this on - changes LGTM and I approve of the additional logging. > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17753) Include GitSHA in nodetool version output
[ https://issues.apache.org/jira/browse/CASSANDRA-17753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623925#comment-17623925 ] Caleb Rackliffe commented on CASSANDRA-17753: - [~smiklosovic] +1 on your logging addendum, FWIW Do we have a committer? > Include GitSHA in nodetool version output > - > > Key: CASSANDRA-17753 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17753 > Project: Cassandra > Issue Type: New Feature > Components: Tool/nodetool >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > It can be useful to see specifically which Git SHA a running instance of > Cassandra was built with, especially when running clusters in development for > soak testing. > > I have a patch ready for this, and am preparing it now. -- This message was sent by Atlassian Jira (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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623923#comment-17623923
]
Brandon Williams commented on CASSANDRA-17928:
--
I don't think it fails on 4.0, but we can see when it finishes
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/682/workflows/69d0d7ac-52bc-4f81-b7cd-fdfe7a75c2b7].
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623922#comment-17623922
]
Andres de la Peña commented on CASSANDRA-17928:
---
The patch looks good to me. I have started another pair of repeated runs for
[4.1|https://app.circleci.com/pipelines/github/adelapena/cassandra/2328/workflows/50f33d9b-c7c6-4aa9-bac9-22ac78ad6b8c]
and
[trunk|https://app.circleci.com/pipelines/github/adelapena/cassandra/2327/workflows/aa732ff3-304b-4f0d-ab3c-4662f0a9ebe2]
since this one is hard to reproduce.
I think that [the test also exists in
4.0|https://github.com/apache/cassandra/blob/cassandra-4.0/test/unit/org/apache/cassandra/db/commitlog/CommitLogInitWithExceptionTest.java#L84-L93],
although in that branch the thread is not wrapped. Should we port the fix, or
the test doesn't fail in that branch?
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17928:
--
Reviewers: Andres de la Peña
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17928:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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] [Assigned] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17928:
Assignee: Brandon Williams
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623903#comment-17623903
]
Brandon Williams commented on CASSANDRA-17928:
--
I removed the 1000ms sleep in favor of awaiting termination on the executor
[here|https://github.com/driftx/cassandra/commit/6d7b2aff20c8b3113fef72b186f2caadd39b3aeb].
||Branch||CI||
|[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-17928]|[circle
10k|https://app.circleci.com/pipelines/github/driftx/cassandra/679/workflows/45d0f69d-e99d-4f2b-b69c-af4ad7f8be18/jobs/7504]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17928-trunk]|[circle
10k|https://app.circleci.com/pipelines/github/driftx/cassandra/680/workflows/51868e19-35d1-46fc-af02-9ec6f85bddd0/jobs/7506]
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17928) Test Failure: org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
[
https://issues.apache.org/jira/browse/CASSANDRA-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17928:
-
Test and Documentation Plan: run CI
Status: Patch Available (was: Open)
> Test Failure:
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException-compression
> -
>
> Key: CASSANDRA-17928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17928
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.db.commitlog/CommitLogInitWithExceptionTest/testCommitLogInitWithException_compression/]
> Failed 1 times in the last 14 runs. Flakiness: 7%, Stability: 92%
> Stacktrace
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest.testCommitLogInitWithException(CommitLogInitWithExceptionTest.java:93)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> {code:java}
> Standard Output
> INFO [main] 2022-09-25 11:43:16,512 Reflections.java:219 - Reflections took
> 1221 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,480 Reflections.java:219 - Reflections took
> 907 ms to scan 8 urls, producing 1756 keys and 6922 values
> INFO [main] 2022-09-25 11:43:17,573 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.compressed.yaml
> DEBUG [main] 2022-09-25 11:43:17,574 YamlConfigurationLoader
> ...[truncated 35568 chars]...
> .apache.cassandra.db.commitlog.CommitLogInitWithExceptionTest$MockCommitLogSegmentMgr.createSegment(CommitLogInitWithExceptionTest.java:106)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$AllocatorRunnable.run(AbstractCommitLogSegmentManager.java:155)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> {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-16606) Update libthrift jar to at least 0.9.3-1, investigate 0.14.0
[ https://issues.apache.org/jira/browse/CASSANDRA-16606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623879#comment-17623879 ] Stefan Miklosovic commented on CASSANDRA-16606: --- [~ivodujmovic] btw if you want to upgrade it, you are very welcome to do that, a patch would be nice to have indeed. I do not recall anymore why this was not left in OPEN at least. We can return to that if you wish and apply your patch. > Update libthrift jar to at least 0.9.3-1, investigate 0.14.0 > > > Key: CASSANDRA-16606 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16606 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Thrift >Reporter: Mark Denihan >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.26, 3.11.12 > > > Cassandra 3.x and 2.x uses libthrift 0.9.2, which has a number of > vulnerabilities associated with it which are applicable to Cassandra; > CVE-2015-3254 > CVE-2018-1320 (CASSANDRA-15424) > CVE-2019-0205 (CASSANDRA-15420) > Updating to 0.9.3-1 will mitigate these, however that branch suffers > CVE-2020-13949. > To mitigate risks from using out of date libthrift versions, Cassandra should > be updated to use 0.14.0 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17990:
--
Status: Review In Progress (was: Patch Available)
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(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-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17990:
--
Test and Documentation Plan: Tested locally using the run.sh instructions.
Screenshots attached to the PR
Status: Patch Available (was: Open)
Patch available at https://github.com/apache/cassandra-website/pull/179
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(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-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17990:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Component/s: Documentation/Website
Reviewers: Michael Semb Wever, Michael Shuler
Status: Open (was: Triage Needed)
Opening ticket
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(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-17988) WEBSITE - Add a dedicated Events page
[ https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623847#comment-17623847 ] Stefano Lottini commented on CASSANDRA-17988: - Of course I can. But I am not very well versed in CSS so I will _try_ to look into it later, unless someone more proficient steps in meanwhile :) > WEBSITE - Add a dedicated Events page > - > > Key: CASSANDRA-17988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17988 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Fix For: NA > > Attachments: events1.png, events2.png > > > This is a proposed "Events" section on the Cassandra website, listing > (approved) events as small cards with a picture, a short description and a > link to the external event website. > The motivation behind this idea, which was discussed briefly on the > [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website] > Slack channel as well, is twofold: on one hand, it is desirable to provide > this information to website visitors, which helps building the community > through dedicated events; on the other hand, the Cassandra blog is > preferrably not 'clogged' with too many event announcements so that it can > retain its primary "technical" role. > I tried to create a page that blends in with the rest of the website > experience, but while doing so I had to make some choices. In particular, I > propose an icon for the section (a circus tent) that I hope conveys a > "playful but not silly" message; moreover, I added the "Events" page to the > "Community" navbar menu to avoid adding another menu, even though all other > "Community" menu items are from the community page. > Also I am aware that the buttons alignment on the cards is imperfect. I blame > my (very limited) css knowledge, this is of course something to improve if > ever this draft gets accepted. > > The PR (which probably should be taken as a WIP, for the aforementioned > button alignment issues if nothing else) is here: > https://github.com/apache/cassandra-website/pull/185 -- This message was sent by Atlassian Jira (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-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623835#comment-17623835
]
Derek Chen-Becker commented on CASSANDRA-17990:
---
Work being tracked in https://github.com/apache/cassandra-website/pull/179
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(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-17990) WEBSITE - Fix formatting that should be links on the "patches" page
Derek Chen-Becker created CASSANDRA-17990:
-
Summary: WEBSITE - Fix formatting that should be links on the
"patches" page
Key: CASSANDRA-17990
URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
Project: Cassandra
Issue Type: Task
Reporter: Derek Chen-Becker
Assignee: Derek Chen-Becker
The [https://cassandra.apache.org/_/development/patches.html] page has several
places where references to other pages are not actual links, but are formatted
as fixed-width text. For example:
Code must follow the {{code_style}} convention
instead of
Code must follow the [code
style|https://cassandra.apache.org/_/development/code_style.html] convention
These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623811#comment-17623811 ] Andres de la Peña commented on CASSANDRA-17987: --- Here are the patches for all brances, with the default lowres: ||Patch||Pre-commit||Separate|| |[3.11|https://github.com/adelapena/cassandra/tree/17987-3.11]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2326/workflows/a88cfbee-09ca-44be-909f-cda773fc216f]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2326/workflows/b1295c87-c1a9-4cef-a529-f106cf5c307d]| |[4.0|https://github.com/adelapena/cassandra/tree/17987-4.0]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2325/workflows/9761258f-344c-43a2-997a-876a768bbc08] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2325/workflows/af7d2ed5-a6ba-4bad-9b43-4628bed927d0]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2325/workflows/6327ec8f-99a2-4b4c-9891-d8b7b7acfdbf] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2325/workflows/38d95700-c941-4406-b9d9-59a37a3943f8]| |[4.1|https://github.com/adelapena/cassandra/tree/17987-4.1]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2324/workflows/bc0d5ac4-c2a2-4fc7-b1d4-e78c76a02b35] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2324/workflows/3b5e3fa6-7083-4b2e-9486-981d0ee44016]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2324/workflows/39baf104-35ca-4e43-b484-f72d63ff3796] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2324/workflows/f6834279-7191-44e0-8acf-5ecfb9abdd80]| |[trunk|https://github.com/apache/cassandra/pull/1947]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2322/workflows/852513ca-f285-462b-acd2-a93e61a6ae62] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2322/workflows/dc5d2354-29e5-4129-bc9d-a24cebf679c6]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2322/workflows/13fafad6-51a7-4a63-8e09-946ebe218dff] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2322/workflows/c4c23360-4124-4369-82aa-fbdbbf7c2ded]| If it looks good I'll prepare runs for mid and high. > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[
https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623794#comment-17623794
]
Andres de la Peña commented on CASSANDRA-17987:
---
{quote}Let's not do it mandatory.
{quote}
Agree, I've left it as not mandatory.
{quote}I think you missed the keyspaces ones in the JDK11 pre-commit workflow.
{quote}
Good catch, I have added them
([workflow|https://app.circleci.com/pipelines/github/adelapena/cassandra/2319/workflows/017df4a7-4cb0-41c6-81e9-a22ebdb29761]).
{quote}I just checked we run cdc also with 3.11. I guess we will have to add
them there too.
{quote}
Yep, I'll prepare a patch for 3.11.
I'll post the patches for the rest of the branches in a bit, they are almost
ready.
> CircleCI: Add jobs for running specialized unit tests with Java 11
> --
>
> Key: CASSANDRA-17987
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17987
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> CircleCI has a set of jobs for running specialiazed unit tests that are only
> run with Java 8:
> * utests_compression
> * utests_system_keyspace_directory
> * utests_trie
> * utests_stress
> * utests_long
> * utests_fqltool
> It should probably be possible to run these tests with Java 11 tool.
> Rather than creating a ticket for every job, it's probably easier to use a
> single ticket for all of them. This should give us an overall vision for
> deciding job names, approval steps, etc. Also, the required config changes
> should be quite minimal and doing all of them at once should save us both
> effort and test runs.
--
This message was sent by Atlassian Jira
(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-15531) Improve docs on disk_access_mode, specifically post CASSANDRA-8464
[
https://issues.apache.org/jira/browse/CASSANDRA-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623790#comment-17623790
]
Michael Semb Wever commented on CASSANDRA-15531:
I am not sure I agree with this. We see it sometimes, more often with DSE, but
not enough to warrant a default change from {{`disk_access_mode: auto`}}
Switching to mmap_index_only comes with a cost (higher heap usage), and I
suspect it wiser to only do when warranted.
Docs can be improved to help troubleshoot and document when the change is
warranted.
> Improve docs on disk_access_mode, specifically post CASSANDRA-8464
> --
>
> Key: CASSANDRA-15531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15531
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Erick Ramirez (deprecated)
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: documentation
>
> h2. Background
> [~tsteinmaurer] brought up [on
> Slack|https://the-asf.slack.com/archives/CJZLTM05A/p1580298424288700] that
> they've been hit by the `oom-killer` as a result of SSTables being mmaped.
> h2. Action
> Based on feedback from Thomas Steinmaurer, Jean Carlo & Sam Kearon, I am
> going to push the info I've written in this KB article to the official docs –
> [Increased memory use on nodes after upgrading to DSE 5.0 or DSE
> 5.1|https://support.datastax.com/s/article/Increased-memory-use-on-nodes-after-upgrading-to-DSE-50-or-DSE-51].
> I will revise it specifically for affected OSS versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15531) Improve docs on disk_access_mode, specifically post CASSANDRA-8464
[ https://issues.apache.org/jira/browse/CASSANDRA-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15531: --- Description: h2. Background [~tsteinmaurer] brought up [on Slack|https://the-asf.slack.com/archives/CJZLTM05A/p1580298424288700] that they've been hit by the `oom-killer` as a result of SSTables being mmaped. h2. Action Based on feedback from Thomas Steinmaurer, Jean Carlo & Sam Kearon, I am going to push the info I've written in this KB article to the official docs – [Increased memory use on nodes after upgrading to DSE 5.0 or DSE 5.1|https://support.datastax.com/s/article/Increased-memory-use-on-nodes-after-upgrading-to-DSE-50-or-DSE-51]. I will revise it specifically for affected OSS versions. was: h2. Background [~tsteinmaurer] brought up [on Slack|https://the-asf.slack.com/archives/CJZLTM05A/p1580298424288700] that they've been hit by the `oom-killer` as a result of SSTables being mmaped. h2. Action Based on feedback from Thomas Steinmaurer, Jean Carlo & Sam Kearon, I am going to push the info I've written in this KB article to the official docs – [Increased memory use on nodes after upgrading to DSE 5.0 or DSE 5.1|https://support.datastax.com/hc/en-us/articles/360027838911]. I will revise it specifically for affected OSS versions. > Improve docs on disk_access_mode, specifically post CASSANDRA-8464 > -- > > Key: CASSANDRA-15531 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15531 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez (deprecated) >Assignee: Erick Ramirez >Priority: Normal > Labels: documentation > > h2. Background > [~tsteinmaurer] brought up [on > Slack|https://the-asf.slack.com/archives/CJZLTM05A/p1580298424288700] that > they've been hit by the `oom-killer` as a result of SSTables being mmaped. > h2. Action > Based on feedback from Thomas Steinmaurer, Jean Carlo & Sam Kearon, I am > going to push the info I've written in this KB article to the official docs – > [Increased memory use on nodes after upgrading to DSE 5.0 or DSE > 5.1|https://support.datastax.com/s/article/Increased-memory-use-on-nodes-after-upgrading-to-DSE-50-or-DSE-51]. > I will revise it specifically for affected OSS versions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17988) WEBSITE - Add a dedicated Events page
[ https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623772#comment-17623772 ] Erick Ramirez commented on CASSANDRA-17988: --- [~stefano_lottini] thanks for doing this! Any chance you could modify the stylesheet so there are only two "cards" side-by-side vs the four we have now? This is to maximise our ability to place a square image that would serve as ad. What do you think? 🙂 > WEBSITE - Add a dedicated Events page > - > > Key: CASSANDRA-17988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17988 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Fix For: NA > > Attachments: events1.png, events2.png > > > This is a proposed "Events" section on the Cassandra website, listing > (approved) events as small cards with a picture, a short description and a > link to the external event website. > The motivation behind this idea, which was discussed briefly on the > [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website] > Slack channel as well, is twofold: on one hand, it is desirable to provide > this information to website visitors, which helps building the community > through dedicated events; on the other hand, the Cassandra blog is > preferrably not 'clogged' with too many event announcements so that it can > retain its primary "technical" role. > I tried to create a page that blends in with the rest of the website > experience, but while doing so I had to make some choices. In particular, I > propose an icon for the section (a circus tent) that I hope conveys a > "playful but not silly" message; moreover, I added the "Events" page to the > "Community" navbar menu to avoid adding another menu, even though all other > "Community" menu items are from the community page. > Also I am aware that the buttons alignment on the cards is imperfect. I blame > my (very limited) css knowledge, this is of course something to improve if > ever this draft gets accepted. > > The PR (which probably should be taken as a WIP, for the aforementioned > button alignment issues if nothing else) is here: > https://github.com/apache/cassandra-website/pull/185 -- This message was sent by Atlassian Jira (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-17988) WEBSITE - Add a dedicated Events page
[ https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17988: -- Status: Review In Progress (was: Patch Available) > WEBSITE - Add a dedicated Events page > - > > Key: CASSANDRA-17988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17988 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Fix For: NA > > Attachments: events1.png, events2.png > > > This is a proposed "Events" section on the Cassandra website, listing > (approved) events as small cards with a picture, a short description and a > link to the external event website. > The motivation behind this idea, which was discussed briefly on the > [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website] > Slack channel as well, is twofold: on one hand, it is desirable to provide > this information to website visitors, which helps building the community > through dedicated events; on the other hand, the Cassandra blog is > preferrably not 'clogged' with too many event announcements so that it can > retain its primary "technical" role. > I tried to create a page that blends in with the rest of the website > experience, but while doing so I had to make some choices. In particular, I > propose an icon for the section (a circus tent) that I hope conveys a > "playful but not silly" message; moreover, I added the "Events" page to the > "Community" navbar menu to avoid adding another menu, even though all other > "Community" menu items are from the community page. > Also I am aware that the buttons alignment on the cards is imperfect. I blame > my (very limited) css knowledge, this is of course something to improve if > ever this draft gets accepted. > > The PR (which probably should be taken as a WIP, for the aforementioned > button alignment issues if nothing else) is here: > https://github.com/apache/cassandra-website/pull/185 -- This message was sent by Atlassian Jira (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-17988) WEBSITE - Add a dedicated Events page
[ https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17988: -- Issue Type: Task (was: Improvement) > WEBSITE - Add a dedicated Events page > - > > Key: CASSANDRA-17988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17988 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Fix For: NA > > Attachments: events1.png, events2.png > > > This is a proposed "Events" section on the Cassandra website, listing > (approved) events as small cards with a picture, a short description and a > link to the external event website. > The motivation behind this idea, which was discussed briefly on the > [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website] > Slack channel as well, is twofold: on one hand, it is desirable to provide > this information to website visitors, which helps building the community > through dedicated events; on the other hand, the Cassandra blog is > preferrably not 'clogged' with too many event announcements so that it can > retain its primary "technical" role. > I tried to create a page that blends in with the rest of the website > experience, but while doing so I had to make some choices. In particular, I > propose an icon for the section (a circus tent) that I hope conveys a > "playful but not silly" message; moreover, I added the "Events" page to the > "Community" navbar menu to avoid adding another menu, even though all other > "Community" menu items are from the community page. > Also I am aware that the buttons alignment on the cards is imperfect. I blame > my (very limited) css knowledge, this is of course something to improve if > ever this draft gets accepted. > > The PR (which probably should be taken as a WIP, for the aforementioned > button alignment issues if nothing else) is here: > https://github.com/apache/cassandra-website/pull/185 -- This message was sent by Atlassian Jira (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-17988) WEBSITE - Add a dedicated Events page
[ https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17988: -- Summary: WEBSITE - Add a dedicated Events page (was: A dedicated "events" section on Cassandra website) > WEBSITE - Add a dedicated Events page > - > > Key: CASSANDRA-17988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17988 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Fix For: NA > > Attachments: events1.png, events2.png > > > This is a proposed "Events" section on the Cassandra website, listing > (approved) events as small cards with a picture, a short description and a > link to the external event website. > The motivation behind this idea, which was discussed briefly on the > [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website] > Slack channel as well, is twofold: on one hand, it is desirable to provide > this information to website visitors, which helps building the community > through dedicated events; on the other hand, the Cassandra blog is > preferrably not 'clogged' with too many event announcements so that it can > retain its primary "technical" role. > I tried to create a page that blends in with the rest of the website > experience, but while doing so I had to make some choices. In particular, I > propose an icon for the section (a circus tent) that I hope conveys a > "playful but not silly" message; moreover, I added the "Events" page to the > "Community" navbar menu to avoid adding another menu, even though all other > "Community" menu items are from the community page. > Also I am aware that the buttons alignment on the cards is imperfect. I blame > my (very limited) css knowledge, this is of course something to improve if > ever this draft gets accepted. > > The PR (which probably should be taken as a WIP, for the aforementioned > button alignment issues if nothing else) is here: > https://github.com/apache/cassandra-website/pull/185 -- This message was sent by Atlassian Jira (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-17988) A dedicated "events" section on Cassandra website
[
https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623759#comment-17623759
]
Erick Ramirez edited comment on CASSANDRA-17988 at 10/25/22 11:11 AM:
--
Patch:
||Branch||PR||
|{{trunk}}|[#185|https://github.com/apache/cassandra-website/pull/185]|
!events1.png|width=300!
!events2.png|width=300!
was (Author: JIRAUSER285101):
Patch:
||Branch||PR||
|{{trunk}}|[#185|https://github.com/apache/cassandra-website/pull/185]|
> A dedicated "events" section on Cassandra website
> -
>
> Key: CASSANDRA-17988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17988
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Stefano Lottini
>Assignee: Stefano Lottini
>Priority: Normal
> Fix For: NA
>
> Attachments: events1.png, events2.png
>
>
> This is a proposed "Events" section on the Cassandra website, listing
> (approved) events as small cards with a picture, a short description and a
> link to the external event website.
> The motivation behind this idea, which was discussed briefly on the
> [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website]
> Slack channel as well, is twofold: on one hand, it is desirable to provide
> this information to website visitors, which helps building the community
> through dedicated events; on the other hand, the Cassandra blog is
> preferrably not 'clogged' with too many event announcements so that it can
> retain its primary "technical" role.
> I tried to create a page that blends in with the rest of the website
> experience, but while doing so I had to make some choices. In particular, I
> propose an icon for the section (a circus tent) that I hope conveys a
> "playful but not silly" message; moreover, I added the "Events" page to the
> "Community" navbar menu to avoid adding another menu, even though all other
> "Community" menu items are from the community page.
> Also I am aware that the buttons alignment on the cards is imperfect. I blame
> my (very limited) css knowledge, this is of course something to improve if
> ever this draft gets accepted.
>
> The PR (which probably should be taken as a WIP, for the aforementioned
> button alignment issues if nothing else) is here:
> https://github.com/apache/cassandra-website/pull/185
--
This message was sent by Atlassian Jira
(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-17988) A dedicated "events" section on Cassandra website
[
https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17988:
--
Test and Documentation Plan: Stage locally and verify that all elements
render as expected
Status: Patch Available (was: Open)
Patch:
||Branch||PR||
|{{trunk}}|[#185|https://github.com/apache/cassandra-website/pull/185]|
> A dedicated "events" section on Cassandra website
> -
>
> Key: CASSANDRA-17988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17988
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Stefano Lottini
>Assignee: Stefano Lottini
>Priority: Normal
> Fix For: NA
>
> Attachments: events1.png, events2.png
>
>
> This is a proposed "Events" section on the Cassandra website, listing
> (approved) events as small cards with a picture, a short description and a
> link to the external event website.
> The motivation behind this idea, which was discussed briefly on the
> [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website]
> Slack channel as well, is twofold: on one hand, it is desirable to provide
> this information to website visitors, which helps building the community
> through dedicated events; on the other hand, the Cassandra blog is
> preferrably not 'clogged' with too many event announcements so that it can
> retain its primary "technical" role.
> I tried to create a page that blends in with the rest of the website
> experience, but while doing so I had to make some choices. In particular, I
> propose an icon for the section (a circus tent) that I hope conveys a
> "playful but not silly" message; moreover, I added the "Events" page to the
> "Community" navbar menu to avoid adding another menu, even though all other
> "Community" menu items are from the community page.
> Also I am aware that the buttons alignment on the cards is imperfect. I blame
> my (very limited) css knowledge, this is of course something to improve if
> ever this draft gets accepted.
>
> The PR (which probably should be taken as a WIP, for the aforementioned
> button alignment issues if nothing else) is here:
> https://github.com/apache/cassandra-website/pull/185
--
This message was sent by Atlassian Jira
(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-17955) Race condition on repair snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623757#comment-17623757
]
Stefan Miklosovic commented on CASSANDRA-17955:
---
I run pipeline with the proposed approach (running it in Stage) and while it
seems to be ok in 4.0, it does not work in 4.1, there are dozens of errors,
reproducible locally too. It seems like it is stuck and then it just timeouts.
I do not have a lot of time to investigate what is going on here, I run the
original patch and passes the pipeline just fine so I will go with that one.
I ll formally prepare all the branches and builds and merge the original and
already approved approach.
> Race condition on repair snapshots
> --
>
> Key: CASSANDRA-17955
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17955
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Snapshots
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Labels: 4.0
> Fix For: 4.0.x, 4.1-rc, 4.x
>
> Attachments: signature.asc
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If an endpoint is convicted and that endpoint is a coordinator then
> ActiveRepairService::removeParentRepairSession is called.
> The issue is that this occurs on clearSnapshotExecutor and can happen while
> RepairMessageVerbHandler is in process of taking a snapshot. So then you get
> a race condition and clearSnapshot will throw a
> java.nio.file.DirectoryNotEmptyException
>
> {code:java}
> public static void deleteRecursiveWithThrottle(File dir, RateLimiter
> rateLimiter)
> {
> if (dir.isDirectory())
> {
> String[] children = dir.list();
> for (String child : children)
> deleteRecursiveWithThrottle(new File(dir, child), rateLimiter);
> }
> // The directory is now empty so now it can be smoked
> deleteWithConfirmWithThrottle(dir, rateLimiter);
> } {code}
> Due to the directory not being empty when it goes to remove the directory at
> the end.
--
This message was sent by Atlassian Jira
(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-17988) A dedicated "events" section on Cassandra website
[ https://issues.apache.org/jira/browse/CASSANDRA-17988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17988: -- Change Category: Semantic Complexity: Normal Fix Version/s: NA Reviewers: Erick Ramirez Assignee: Stefano Lottini Status: Open (was: Triage Needed) > A dedicated "events" section on Cassandra website > - > > Key: CASSANDRA-17988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17988 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Stefano Lottini >Assignee: Stefano Lottini >Priority: Normal > Fix For: NA > > Attachments: events1.png, events2.png > > > This is a proposed "Events" section on the Cassandra website, listing > (approved) events as small cards with a picture, a short description and a > link to the external event website. > The motivation behind this idea, which was discussed briefly on the > [cassandra-website|https://issues.apache.org/jira/browse/CASSANDRA-website] > Slack channel as well, is twofold: on one hand, it is desirable to provide > this information to website visitors, which helps building the community > through dedicated events; on the other hand, the Cassandra blog is > preferrably not 'clogged' with too many event announcements so that it can > retain its primary "technical" role. > I tried to create a page that blends in with the rest of the website > experience, but while doing so I had to make some choices. In particular, I > propose an icon for the section (a circus tent) that I hope conveys a > "playful but not silly" message; moreover, I added the "Events" page to the > "Community" navbar menu to avoid adding another menu, even though all other > "Community" menu items are from the community page. > Also I am aware that the buttons alignment on the cards is imperfect. I blame > my (very limited) css knowledge, this is of course something to improve if > ever this draft gets accepted. > > The PR (which probably should be taken as a WIP, for the aforementioned > button alignment issues if nothing else) is here: > https://github.com/apache/cassandra-website/pull/185 -- This message was sent by Atlassian Jira (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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623743#comment-17623743 ] Berenguer Blasi commented on CASSANDRA-17987: - Good thx! > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (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-17987) CircleCI: Add jobs for running specialized unit tests with Java 11
[ https://issues.apache.org/jira/browse/CASSANDRA-17987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623735#comment-17623735 ] Andres de la Peña commented on CASSANDRA-17987: --- We meant CASSANDRA-17989. > CircleCI: Add jobs for running specialized unit tests with Java 11 > -- > > Key: CASSANDRA-17987 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17987 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > > CircleCI has a set of jobs for running specialiazed unit tests that are only > run with Java 8: > * utests_compression > * utests_system_keyspace_directory > * utests_trie > * utests_stress > * utests_long > * utests_fqltool > It should probably be possible to run these tests with Java 11 tool. > Rather than creating a ticket for every job, it's probably easier to use a > single ticket for all of them. This should give us an overall vision for > deciding job names, approval steps, etc. Also, the required config changes > should be quite minimal and doing all of them at once should save us both > effort and test runs. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
