[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679398#comment-17679398
]
Jeff Jirsa commented on CASSANDRA-18134:
Not a review, but really interesting patch.
This is not a suggestion to change, just curious: did you consider using
something other than a metadata flag for partition deletions? Like a second
bloom filter of partition deletions? I ask because if a use case regularly does
partition deletions, the metadata flag seems like it reverts back to the
current behavior (any delete = include the file)?
(Also reminded me CASSANDRA-9843 was a thing that was opened once, years ago).
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice instead of min/max clusterings.
> The difference is that for slices there is available the type of a bound
> rather than just a clustering. In particular it will provide the information
> whether the lower and upper bound of an sstable is opened or closed.
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # The above two changes required to introduce a new major format for SSTables
> - {{oa}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian 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 (d7662b074 -> fe794cc18)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard d7662b074 generate docs for 5dd84ab2 new fe794cc18 generate docs for 5dd84ab2 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 (d7662b074) \ N -- N -- N refs/heads/asf-staging (fe794cc18) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (0515d8113 -> d7662b074)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 0515d8113 generate docs for 5dd84ab2 new d7662b074 generate docs for 5dd84ab2 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 (0515d8113) \ N -- N -- N refs/heads/asf-staging (d7662b074) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (eb59db85a -> 0515d8113)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard eb59db85a generate docs for 5dd84ab2 new 0515d8113 generate docs for 5dd84ab2 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 (eb59db85a) \ N -- N -- N refs/heads/asf-staging (0515d8113) 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 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679362#comment-17679362
]
Michael Semb Wever commented on CASSANDRA-17869:
bq. CASSANDRA-18017 …
There's currently no shared/stashed files between stages and splits in jenkins.
The flag would be useful for repeated runs, but for the existing test stages it
requires them first to be brought on-tree and then the stash and unstash
functionality to be implemented. For example stash is being tested here:
https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/17869/trunk#diff-917491029f94ac1ce6c114a542d2a8738ce1f2d1e866eaffe7189d2139250200R236-R238
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17199:
-
Reviewers: Jon Meredith
Status: Review In Progress (was: Patch Available)
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679350#comment-17679350
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
Thanks [~adelapena] , I missed CASSANDRA-18017 was created already. I will link
it here and to the original ticket so we don't forget about it as it is a great
improvement.
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679349#comment-17679349
]
Andres de la Peña commented on CASSANDRA-17869:
---
CASSANDRA-18017 was created for that, it would be great if the flag is added
here.
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18181) Fix tests post JDK-8210522
[
https://issues.apache.org/jira/browse/CASSANDRA-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679342#comment-17679342
]
Ekaterina Dimitrova commented on CASSANDRA-18181:
-
As part of another ticket there were new images pushed and CI was in a broken
state for a bit until the second image was also pushed. This broke the Jenkins
CI build I had.
I just restarted the build
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2212/]
> Fix tests post JDK-8210522
> --
>
> Key: CASSANDRA-18181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18181
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
>
> From JDK-8210522:
> {code:java}
> Core reflection has a filtering mechanism to hide security and integrity
> sensitive fields and methods from Class getXXXField(s) and getXXXMethod(s).
> The filtering mechanism has been used for several releases to hide security
> sensitive fields such as System.security and Class.classLoader.
> This CSR proposes to extend the filters to hide fields from a number of
> highly security sensitive classes in java.lang.reflect and java.lang.invoke.
> {code}
> We are using at a few places in our tests
> {code:java}
> Field.class.getDeclaredField("modifiers");{code}
> This breaks as expected when tests are run with JDK17, example:
>
> {code:java}
> java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:79)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NoSuchFieldException: modifiers at
> java.base/java.lang.Class.getDeclaredField(Class.java:2610)
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:70)
>
> ... 15 more{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-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679332#comment-17679332
]
Brandon Williams commented on CASSANDRA-11537:
--
LGTM, the cqlshlib failures can be ignored and are fallout from CASSANDRA-18088
being committed. +1, back to you, [~paulo].
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679228#comment-17679228 ] Brandon Williams edited comment on CASSANDRA-18148 at 1/20/23 9:36 PM: --- Patches to suppress: ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/795/workflows/e3fcd4c8-501a-4baf-84ea-bd01f5ee344a]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/793/workflows/b360fdf0-837e-440e-b22a-2891c74a6545]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/797/workflows/1a5ba6cb-be5e-4291-a55c-8fa86950b95d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/797/workflows/3993a7a6-65be-4ca8-8a5e-7d3d29c147e8]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/796/workflows/a96803ec-1378-4969-af4f-fdcc1906ae93], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/796/workflows/598c-3449-418e-b276-115eea564165]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/794/workflows/f5fe2081-70b4-4674-b39e-11fcf5aced13], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/794/workflows/e590663b-bf82-4704-8d5a-45ccbe3ee45c]| The cqlshlib failures are fallout from CASSANDRA-18088 in the process of being committed. was (Author: brandon.williams): Patches to suppress: ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/795/workflows/e3fcd4c8-501a-4baf-84ea-bd01f5ee344a]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/793/workflows/b360fdf0-837e-440e-b22a-2891c74a6545]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/797/workflows/1a5ba6cb-be5e-4291-a55c-8fa86950b95d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/797/workflows/3993a7a6-65be-4ca8-8a5e-7d3d29c147e8]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/796/workflows/a96803ec-1378-4969-af4f-fdcc1906ae93], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/796/workflows/598c-3449-418e-b276-115eea564165]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/794/workflows/f5fe2081-70b4-4674-b39e-11fcf5aced13], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/794/workflows/e590663b-bf82-4704-8d5a-45ccbe3ee45c]| > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- This message was sent by Atlassian Jira (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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18148: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- This message was sent by Atlassian Jira (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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18121: - Fix Version/s: 4.0.8 4.1.1 4.2 Source Control Link: https://github.com/apache/cassandra-dtest/commit/9cd503ce92b7eeb7e7e9557606d46c01b7267aea Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks for the review! > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.8, 4.1.1, 4.2 > > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- This message was sent by Atlassian Jira (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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18088:
-
Fix Version/s: 4.0.8
4.1.1
4.2
(was: 4.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/0b5248d8c3ef743a8dda42f7be5dadb70e373b51
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks everyone!
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.8, 4.1.1, 4.2
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.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
[cassandra-dtest] 02/02: Fix logging in ttl test
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
commit ba6a2448c3cc1765add601e4d1ac500a0a75d0bc
Author: Brandon Williams
AuthorDate: Tue Jan 17 15:17:53 2023 -0600
Fix logging in ttl test
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
ttl_test.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ttl_test.py b/ttl_test.py
index 7416e9c3..96552de2 100644
--- a/ttl_test.py
+++ b/ttl_test.py
@@ -388,7 +388,7 @@ class TestTTL(Tester):
pytest.fail("should throw InvalidRequest")
if self.cluster.version() >= '3.0': # client warn only on 3.0+
if policy == 'CAP':
-logger.debug("Warning is {}", result.warnings[0])
+logger.debug("Warning is {}".format(result.warnings[0]))
assert 'exceeds maximum supported expiration' in
result.warnings[0], 'Warning not found'
else:
assert not result.warnings, "There should be no warnings"
@@ -591,7 +591,7 @@ class TestRecoverNegativeExpirationDate(TestHelper):
base_dir = os.path.dirname(os.path.abspath(__file__))
corrupt_sstable_dir = os.path.join(base_dir, 'sstables', 'ttl_test',
version)
table_dir = self.get_table_paths('ttl_table')[0]
-logger.debug("Copying sstables from {} into {}", corrupt_sstable_dir,
table_dir)
+logger.debug("Copying sstables from {} into
{}".format(corrupt_sstable_dir, table_dir))
copytree(corrupt_sstable_dir, table_dir)
logger.debug("Load corrupted sstable")
@@ -609,7 +609,7 @@ class TestRecoverNegativeExpirationDate(TestHelper):
reinsert_overflowed_ttl=True,
no_validate=True)
-logger.debug("Executed offline scrub on {}", str(scrubbed_sstables))
+logger.debug("Executed offline scrub on
{}".format(str(scrubbed_sstables)))
logger.debug("Starting node again")
self.cluster.start()
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] 01/02: Add python 3.11 support
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
commit 9cd503ce92b7eeb7e7e9557606d46c01b7267aea
Author: Brandon Williams
AuthorDate: Thu Dec 15 09:14:05 2022 -0600
Add python 3.11 support
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
client_request_metrics_local_remote_test.py | 8
conftest.py | 21 -
consistency_test.py | 2 +-
jmx_test.py | 2 +-
pytest.ini | 15 ++-
rebuild_test.py | 14 --
requirements.txt| 2 +-
tools/misc.py | 5 -
8 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/client_request_metrics_local_remote_test.py
b/client_request_metrics_local_remote_test.py
index 476d4626..8d817f9f 100644
--- a/client_request_metrics_local_remote_test.py
+++ b/client_request_metrics_local_remote_test.py
@@ -9,7 +9,7 @@ since = pytest.mark.since
class TestClientRequestMetricsLocalRemote(Tester):
def test_write_and_read(self):
-session, node = setup(self)
+session, node = setup_test(self)
read_metrics = ClientRequestMetricsContainer(node, 'Read')
write_metrics = ClientRequestMetricsContainer(node, 'Write')
@@ -47,7 +47,7 @@ class TestClientRequestMetricsLocalRemote(Tester):
assert 0 < (r3_r.remote_requests - r2_r.remote_requests)
def test_batch_and_slice(self):
-session, node = setup(self)
+session, node = setup_test(self)
read_metrics = ClientRequestMetricsContainer(node, 'Read')
write_metrics = ClientRequestMetricsContainer(node, 'Write')
@@ -89,7 +89,7 @@ class TestClientRequestMetricsLocalRemote(Tester):
assert 0 < (r3_r.remote_requests - r2_r.remote_requests)
def test_paxos(self):
-session, node = setup(self)
+session, node = setup_test(self)
read_metrics = ClientRequestMetricsContainer(node, 'Read')
write_metrics = ClientRequestMetricsContainer(node, 'Write')
@@ -177,7 +177,7 @@ def setup_schema(session):
session.execute("CREATE TABLE test (id int,ord int,val varchar,PRIMARY KEY
(id, ord));""")
-def setup(obj):
+def setup_test(obj):
cluster = obj.cluster
cluster.populate(2)
diff --git a/conftest.py b/conftest.py
index fac8f26d..5ba3de80 100644
--- a/conftest.py
+++ b/conftest.py
@@ -1,5 +1,8 @@
import copy
-import collections
+try:
+import collections.abc as collections
+except ImportError:
+import collections
import logging
import os
import platform
@@ -149,7 +152,7 @@ def fixture_logging_setup(request):
log_level = logging.INFO
try:
# first see if logging level overridden by user as command line
argument
-log_level_from_option = pytest.config.getoption("--log-level")
+log_level_from_option = request.config.getoption("--log-level")
if log_level_from_option is not None:
log_level = logging.getLevelName(log_level_from_option)
else:
@@ -158,22 +161,22 @@ def fixture_logging_setup(request):
# nope, user didn't specify it as a command line argument to pytest,
check if
# we have a default in the loaded pytest.ini. Note: words are
seperated in variables
# in .ini land with a "_" while the command line arguments use "-"
-if pytest.config.inicfg.get("log_level") is not None:
-log_level =
logging.getLevelName(pytest.config.inicfg.get("log_level"))
+if request.config.inicfg.get("log_level") is not None:
+log_level =
logging.getLevelName(request.config.inicfg.get("log_level"))
logging.root.setLevel(log_level)
logging_format = None
try:
# first see if logging level overridden by user as command line
argument
-log_format_from_option = pytest.config.getoption("--log-format")
+log_format_from_option = request.config.getoption("--log-format")
if log_format_from_option is not None:
logging_format = log_format_from_option
else:
raise ValueError
except ValueError:
-if pytest.config.inicfg.get("log_format") is not None:
-logging_format = pytest.config.inicfg.get("log_format")
+if request.config.inicfg.get("log_format") is not None:
+logging_format = request.config.inicfg.get("log_format")
logging.basicConfig(level=log_level,
format=logging_format)
@@ -192,8 +195,8 @@ def fixture_logging_setup(request):
@pytest.fixture(scope="session")
def log_global_env_facts(fixture_dtest_config, fixture_logging_setup):
-if pytest.config.pluginmanager.hasplugin('junitxml'):
-my_junit =
[cassandra-dtest] branch trunk updated (36da75d9 -> ba6a2448)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git from 36da75d9 remove travis.yml per asf policy new 9cd503ce Add python 3.11 support new ba6a2448 Fix logging in ttl test The 2 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: client_request_metrics_local_remote_test.py | 8 conftest.py | 21 - consistency_test.py | 2 +- jmx_test.py | 2 +- pytest.ini | 15 ++- rebuild_test.py | 14 -- requirements.txt| 2 +- tools/misc.py | 5 - ttl_test.py | 6 +++--- 9 files changed, 48 insertions(+), 27 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 03/04: get newest pip in cassandra-cqlsh-tests.sh
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 4d192f728c9100c84a3215df31f29b5cda64baee
Author: Brandon Williams
AuthorDate: Fri Dec 16 10:09:39 2022 -0600
get newest pip in cassandra-cqlsh-tests.sh
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
pylib/cassandra-cqlsh-tests.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index 951f69a61a..ebdba4efaa 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -73,6 +73,8 @@ fi
set -e # enable immediate exit if venv setup fails
virtualenv --python=$PYTHON_VERSION venv
source venv/bin/activate
+# 3.11 needs the newest pip
+curl -sS https://bootstrap.pypa.io/get-pip.py | $PYTHON_VERSION
pip install -r ${CASSANDRA_DIR}/pylib/requirements.txt
pip freeze
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (8413e9d6fd -> 51e3149169)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 8413e9d6fd Merge branch 'cassandra-4.1' into trunk new 25e4a89f76 Accommodate python 3.11 new 6f20047299 add py311 tests to circle new 4d192f728c get newest pip in cassandra-cqlsh-tests.sh new 51e3149169 Upgrade cython The 4 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: .circleci/config-2_1.yml| 180 +++- .circleci/config-2_1.yml.high_res.patch | 14 +- .circleci/config-2_1.yml.mid_res.patch | 104 ++- .circleci/config.yml| 809 +- .circleci/config.yml.HIGHRES| 809 +- .circleci/config.yml.LOWRES | 809 +- .circleci/config.yml.MIDRES | 1354 +-- CHANGES.txt |1 + pylib/cassandra-cqlsh-tests.sh |4 +- pylib/cqlshlib/saferscanner.py | 28 +- 10 files changed, 3893 insertions(+), 219 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 04/05: get newest pip in cassandra-cqlsh-tests.sh
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 4f32d43d88a36a5dbf0ae1d42bb0280805c99649
Author: Brandon Williams
AuthorDate: Fri Dec 16 10:09:39 2022 -0600
get newest pip in cassandra-cqlsh-tests.sh
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
pylib/cassandra-cqlsh-tests.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index 951f69a61a..ebdba4efaa 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -73,6 +73,8 @@ fi
set -e # enable immediate exit if venv setup fails
virtualenv --python=$PYTHON_VERSION venv
source venv/bin/activate
+# 3.11 needs the newest pip
+curl -sS https://bootstrap.pypa.io/get-pip.py | $PYTHON_VERSION
pip install -r ${CASSANDRA_DIR}/pylib/requirements.txt
pip freeze
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/04: Accommodate python 3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 25e4a89f76917076f0be56fb2b098a7d8f5ba06b Author: Brandon Williams AuthorDate: Sun Dec 4 13:05:19 2022 -0600 Accommodate python 3.11 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18088 --- CHANGES.txt| 1 + pylib/cqlshlib/saferscanner.py | 28 ++-- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 36934c6454..610423f67f 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -102,6 +102,7 @@ Merged from 4.1: * Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming (CASSANDRA-18110) * Fix perpetual load of denylist on read in cases where denylist can never be loaded (CASSANDRA-18116) Merged from 4.0: + * Add support for python 3.11 (CASSANDRA-18088) * Fix formatting of duration in cqlsh (CASSANDRA-18141) * Fix sstable loading of keyspaces named snapshots or backups (CASSANDRA-14013) * Avoid ConcurrentModificationException in STCS/DTCS/TWCS.getSSTables (CASSANDRA-17977) diff --git a/pylib/cqlshlib/saferscanner.py b/pylib/cqlshlib/saferscanner.py index 3cc343033a..5afd8ef172 100644 --- a/pylib/cqlshlib/saferscanner.py +++ b/pylib/cqlshlib/saferscanner.py @@ -19,7 +19,11 @@ # regex in-pattern flags. Any of those can break correct operation of Scanner. import re -from sre_constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS +import six +try: +from sre_constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS +except ImportError: +from re._constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS from sys import version_info @@ -81,4 +85,24 @@ class Py38SaferScanner(SaferScannerBase): self.scanner = re.sre_compile.compile(p) -SaferScanner = Py38SaferScanner if version_info >= (3, 8) else Py36SaferScanner +class Py311SaferScanner(SaferScannerBase): + +def __init__(self, lexicon, flags=0): +self.lexicon = lexicon +p = [] +s = re._parser.State() +s.flags = flags +for phrase, action in lexicon: +gid = s.opengroup() +p.append(re._parser.SubPattern(s, [(SUBPATTERN, (gid, 0, 0, re._parser.parse(phrase, flags))), ])) +s.closegroup(gid, p[-1]) +p = re._parser.SubPattern(s, [(BRANCH, (None, p))]) +self.p = p +self.scanner = re._compiler.compile(p) + + +SaferScanner = Py36SaferScanner if six.PY3 else Py2SaferScanner +if version_info >= (3, 11): +SaferScanner = Py311SaferScanner +elif version_info >= (3, 8): +SaferScanner = Py38SaferScanner - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/05: Accommodate python 3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit cd38edbb41bdf0babdb77c62f09650ae0a28f77c Author: Brandon Williams AuthorDate: Sun Dec 4 13:05:19 2022 -0600 Accommodate python 3.11 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18088 --- CHANGES.txt| 1 + pylib/cqlshlib/saferscanner.py | 28 ++-- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 1352d00b26..ed0e5dc731 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -3,6 +3,7 @@ * Streaming progress virtual table lock contention can trigger TCP_USER_TIMEOUT and fail streaming (CASSANDRA-18110) * Fix perpetual load of denylist on read in cases where denylist can never be loaded (CASSANDRA-18116) Merged from 4.0: + * Add support for python 3.11 (CASSANDRA-18088) * Fix formatting of duration in cqlsh (CASSANDRA-18141) * Fix sstable loading of keyspaces named snapshots or backups (CASSANDRA-14013) * Avoid ConcurrentModificationException in STCS/DTCS/TWCS.getSSTables (CASSANDRA-17977) diff --git a/pylib/cqlshlib/saferscanner.py b/pylib/cqlshlib/saferscanner.py index 3cc343033a..5afd8ef172 100644 --- a/pylib/cqlshlib/saferscanner.py +++ b/pylib/cqlshlib/saferscanner.py @@ -19,7 +19,11 @@ # regex in-pattern flags. Any of those can break correct operation of Scanner. import re -from sre_constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS +import six +try: +from sre_constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS +except ImportError: +from re._constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS from sys import version_info @@ -81,4 +85,24 @@ class Py38SaferScanner(SaferScannerBase): self.scanner = re.sre_compile.compile(p) -SaferScanner = Py38SaferScanner if version_info >= (3, 8) else Py36SaferScanner +class Py311SaferScanner(SaferScannerBase): + +def __init__(self, lexicon, flags=0): +self.lexicon = lexicon +p = [] +s = re._parser.State() +s.flags = flags +for phrase, action in lexicon: +gid = s.opengroup() +p.append(re._parser.SubPattern(s, [(SUBPATTERN, (gid, 0, 0, re._parser.parse(phrase, flags))), ])) +s.closegroup(gid, p[-1]) +p = re._parser.SubPattern(s, [(BRANCH, (None, p))]) +self.p = p +self.scanner = re._compiler.compile(p) + + +SaferScanner = Py36SaferScanner if six.PY3 else Py2SaferScanner +if version_info >= (3, 11): +SaferScanner = Py311SaferScanner +elif version_info >= (3, 8): +SaferScanner = Py38SaferScanner - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/05: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9471ee762c59df1b5158286057df836c37075888 Merge: 7c86e18baf b43293e200 Author: Brandon Williams AuthorDate: Fri Jan 20 15:25:23 2023 -0600 Merge branch 'cassandra-4.0' into cassandra-4.1 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 04/05: convert cqlshlib from nose to pytest
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit f6933a041901861e526b44af6fc974b29b33982e
Author: Brandon Williams
AuthorDate: Fri Dec 16 12:29:57 2022 -0600
convert cqlshlib from nose to pytest
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18088
---
pylib/cassandra-cqlsh-tests.sh | 2 +-
pylib/cqlshlib/test/cassconnect.py | 6 +++---
pylib/cqlshlib/test/test_sslhandling.py | 8
pylib/pytest.ini| 2 ++
pylib/requirements.txt | 3 +--
5 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index 2b14941856..f039ba8cf8 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -129,7 +129,7 @@ ccm start --wait-for-binary-proto
cd ${CASSANDRA_DIR}/pylib/cqlshlib/
set +e # disable immediate exit from this point
-nosetests
+pytest
RETURN="$?"
ccm remove
diff --git a/pylib/cqlshlib/test/cassconnect.py
b/pylib/cqlshlib/test/cassconnect.py
index c4eae0ec8a..909e88ae62 100644
--- a/pylib/cqlshlib/test/cassconnect.py
+++ b/pylib/cqlshlib/test/cassconnect.py
@@ -20,7 +20,7 @@ import io
import os.path
import random
import string
-from nose.tools import nottest
+import pytest
from .basecase import TEST_HOST, TEST_PORT, cql, cqlsh, cqlshlog, policy,
quote_name, test_dir
from .run_cqlsh import run_cqlsh, call_cqlsh
@@ -152,7 +152,7 @@ def cql_rule_set():
class DEFAULTVAL: pass
-@nottest
+@pytest.mark.skip(reason="not a test")
def testrun_cqlsh(keyspace=DEFAULTVAL, **kwargs):
# use a positive default sentinel so that keyspace=None can be used
# to override the default behavior
@@ -161,7 +161,7 @@ def testrun_cqlsh(keyspace=DEFAULTVAL, **kwargs):
return run_cqlsh(keyspace=keyspace, **kwargs)
-@nottest
+@pytest.mark.skip(reason="not a test")
def testcall_cqlsh(keyspace=None, **kwargs):
if keyspace is None:
keyspace = get_keyspace()
diff --git a/pylib/cqlshlib/test/test_sslhandling.py
b/pylib/cqlshlib/test/test_sslhandling.py
index 347fe2a114..a96089d866 100644
--- a/pylib/cqlshlib/test/test_sslhandling.py
+++ b/pylib/cqlshlib/test/test_sslhandling.py
@@ -17,11 +17,11 @@
from cassandra.policies import SimpleConvictionPolicy
from cassandra.pool import Host
from cqlshlib.sslhandling import ssl_settings
-from nose.tools import assert_raises
import unittest
import os
import ssl
+import pytest
class SslSettingsTest(unittest.TestCase):
@@ -53,7 +53,7 @@ class SslSettingsTest(unittest.TestCase):
def test_invalid_ssl_versions_from_env(self):
msg = "invalid_ssl is not a valid SSL protocol, please use one of
TLSv1, TLSv1_1, or TLSv1_2"
-with assert_raises(SystemExit) as error:
+with pytest.raises(SystemExit) as error:
self._test_ssl_version_from_env('invalid_ssl')
assert msg == error.exception.message
@@ -69,7 +69,7 @@ class SslSettingsTest(unittest.TestCase):
def test_invalid_ssl_version_config(self):
msg = "invalid_ssl is not a valid SSL protocol, please use one of
TLSv1, TLSv1_1, or TLSv1_2"
-with assert_raises(SystemExit) as error:
+with pytest.raises(SystemExit) as error:
ssl_settings(self.host, os.path.join('test', 'config',
'sslhandling_invalid.config'))
assert msg in error.exception.message
-
\ No newline at end of file
+
diff --git a/pylib/pytest.ini b/pylib/pytest.ini
new file mode 100644
index 00..d360f07d68
--- /dev/null
+++ b/pylib/pytest.ini
@@ -0,0 +1,2 @@
+[pytest]
+addopts = --junit-xml=nosetests.xml
diff --git a/pylib/requirements.txt b/pylib/requirements.txt
index 59ff479456..8788690638 100644
--- a/pylib/requirements.txt
+++ b/pylib/requirements.txt
@@ -11,8 +11,7 @@ docopt
enum34
flaky
mock
-nose
-nose-test-select
+pytest
parse
pycodestyle
psutil
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 04/04: Upgrade cython
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 51e31491695566cdf3e3114d05e592840d3621f1
Author: Brandon Williams
AuthorDate: Tue Jan 17 14:18:56 2023 -0600
Upgrade cython
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
pylib/cassandra-cqlsh-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index ebdba4efaa..ad6ae75368 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -81,7 +81,7 @@ pip freeze
if [ "$cython" = "yes" ]; then
TESTSUITE_NAME="${TESTSUITE_NAME}.cython"
-pip install "Cython>=0.27.2,<0.28"
+pip install "Cython>=0.29.15,<3.0"
cd pylib/; python setup.py build_ext --inplace
cd ${WORKSPACE}
else
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 05/05: Upgrade cython
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 5086b7d0a7378fa6648d85900776e336a765361c
Author: Brandon Williams
AuthorDate: Tue Jan 17 14:18:56 2023 -0600
Upgrade cython
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
pylib/cassandra-cqlsh-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index ebdba4efaa..ad6ae75368 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -81,7 +81,7 @@ pip freeze
if [ "$cython" = "yes" ]; then
TESTSUITE_NAME="${TESTSUITE_NAME}.cython"
-pip install "Cython>=0.27.2,<0.28"
+pip install "Cython>=0.29.15,<3.0"
cd pylib/; python setup.py build_ext --inplace
cd ${WORKSPACE}
else
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 03/05: get newest pip in cassandra-cqlsh-tests.sh
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 563a26c6b1493f46ebb597085ae589f1835acd50
Author: Brandon Williams
AuthorDate: Fri Dec 16 10:09:39 2022 -0600
get newest pip in cassandra-cqlsh-tests.sh
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
pylib/cassandra-cqlsh-tests.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index 35d759bf8a..2b14941856 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -81,6 +81,8 @@ fi
set -e # enable immediate exit if venv setup fails
virtualenv --python=$PYTHON_VERSION venv
source venv/bin/activate
+# 3.11 needs the newest pip
+curl -sS https://bootstrap.pypa.io/get-pip.py | $PYTHON_VERSION
pip install -r ${CASSANDRA_DIR}/pylib/requirements.txt
pip freeze
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 05/05: Upgrade cython
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit b43293e200dd95c98bfb3ee436fe05bb18da114f
Author: Brandon Williams
AuthorDate: Tue Jan 17 14:18:56 2023 -0600
Upgrade cython
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18121
---
pylib/cassandra-cqlsh-tests.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index f039ba8cf8..b2d2c500ae 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -89,7 +89,7 @@ pip freeze
if [ "$cython" = "yes" ]; then
TESTSUITE_NAME="${TESTSUITE_NAME}.cython"
-pip install "Cython>=0.27.2,<0.28"
+pip install "Cython>=0.29.15,<3.0"
cd pylib/; python setup.py build_ext --inplace
cd ${WORKSPACE}
else
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (815f7de346 -> b43293e200)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 815f7de346 Merge branch 'cassandra-3.11' into cassandra-4.0 new 0b5248d8c3 Accommodate python 3.11 new d38427a67b add py311 tests to circle new 563a26c6b1 get newest pip in cassandra-cqlsh-tests.sh new f6933a0419 convert cqlshlib from nose to pytest new b43293e200 Upgrade cython The 5 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: .circleci/config-2_1.yml| 180 - .circleci/config-2_1.yml.mid_res.patch | 112 +++- .circleci/config.yml| 693 +++- .circleci/config.yml.HIGHRES| 693 +++- .circleci/config.yml.LOWRES | 693 +++- .circleci/config.yml.MIDRES | 1086 ++- CHANGES.txt |1 + pylib/cassandra-cqlsh-tests.sh |6 +- pylib/cqlshlib/saferscanner.py | 26 +- pylib/cqlshlib/test/cassconnect.py |6 +- pylib/cqlshlib/test/test_sslhandling.py |8 +- pylib/pytest.ini|2 + pylib/requirements.txt |3 +- 13 files changed, 3393 insertions(+), 116 deletions(-) create mode 100644 pylib/pytest.ini - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (7c86e18baf -> 5086b7d0a7)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7c86e18baf Update G1GC settings, and make it default in trunk new 0b5248d8c3 Accommodate python 3.11 new d38427a67b add py311 tests to circle new 563a26c6b1 get newest pip in cassandra-cqlsh-tests.sh new f6933a0419 convert cqlshlib from nose to pytest new b43293e200 Upgrade cython new 9471ee762c Merge branch 'cassandra-4.0' into cassandra-4.1 new cd38edbb41 Accommodate python 3.11 new f66e7dcf33 add py311 tests to circle new 4f32d43d88 get newest pip in cassandra-cqlsh-tests.sh new 5086b7d0a7 Upgrade cython The 10 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: .circleci/config-2_1.yml| 180 - .circleci/config-2_1.yml.high_res.patch | 14 +- .circleci/config-2_1.yml.mid_res.patch | 106 ++- .circleci/config.yml| 991 --- .circleci/config.yml.HIGHRES| 989 --- .circleci/config.yml.LOWRES | 991 --- .circleci/config.yml.MIDRES | 1315 +-- CHANGES.txt |1 + pylib/cassandra-cqlsh-tests.sh |4 +- pylib/cqlshlib/saferscanner.py | 28 +- 10 files changed, 4127 insertions(+), 492 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/05: Accommodate python 3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 0b5248d8c3ef743a8dda42f7be5dadb70e373b51 Author: Brandon Williams AuthorDate: Sun Dec 4 13:05:19 2022 -0600 Accommodate python 3.11 Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18088 --- CHANGES.txt| 1 + pylib/cqlshlib/saferscanner.py | 26 -- 2 files changed, 25 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index d51e991e34..8794ae533a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0.8 + * Add support for python 3.11 (CASSANDRA-18088) * Fix formatting of duration in cqlsh (CASSANDRA-18141) * Fix sstable loading of keyspaces named snapshots or backups (CASSANDRA-14013) * Avoid ConcurrentModificationException in STCS/DTCS/TWCS.getSSTables (CASSANDRA-17977) diff --git a/pylib/cqlshlib/saferscanner.py b/pylib/cqlshlib/saferscanner.py index 8949321dff..6d7ba571af 100644 --- a/pylib/cqlshlib/saferscanner.py +++ b/pylib/cqlshlib/saferscanner.py @@ -20,7 +20,10 @@ import re import six -from sre_constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS +try: +from sre_constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS +except ImportError: +from re._constants import BRANCH, SUBPATTERN, GROUPREF, GROUPREF_IGNORE, GROUPREF_EXISTS from sys import version_info @@ -99,5 +102,24 @@ class Py38SaferScanner(SaferScannerBase): self.scanner = re.sre_compile.compile(p) +class Py311SaferScanner(SaferScannerBase): + +def __init__(self, lexicon, flags=0): +self.lexicon = lexicon +p = [] +s = re._parser.State() +s.flags = flags +for phrase, action in lexicon: +gid = s.opengroup() +p.append(re._parser.SubPattern(s, [(SUBPATTERN, (gid, 0, 0, re._parser.parse(phrase, flags))), ])) +s.closegroup(gid, p[-1]) +p = re._parser.SubPattern(s, [(BRANCH, (None, p))]) +self.p = p +self.scanner = re._compiler.compile(p) + + SaferScanner = Py36SaferScanner if six.PY3 else Py2SaferScanner -SaferScanner = Py38SaferScanner if version_info >= (3, 8) else SaferScanner +if version_info >= (3, 11): +SaferScanner = Py311SaferScanner +elif version_info >= (3, 8): +SaferScanner = Py38SaferScanner - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679317#comment-17679317
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
I just got reminded of something - CASSANDRA-18000
[~adelapena] mentioned we can use it in the splits in Jenkins. Thoughts? If we
can benefit of that flag, do we want this added here while we are on top of the
build scripts or a separate ticket?
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679311#comment-17679311
]
Natnael Adere commented on CASSANDRA-17199:
---
circle ci:
https://app.circleci.com/pipelines/github/NateAdere/cassandra?branch=Cassandra-17199-trunkk
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Natnael Adere updated CASSANDRA-17199:
--
Test and Documentation Plan: Circle ci tests passing
Status: Patch Available (was: In Progress)
Patch for trunk: https://github.com/apache/cassandra/pull/2104
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679303#comment-17679303
]
Ekaterina Dimitrova edited comment on CASSANDRA-18051 at 1/20/23 7:39 PM:
--
Thank you for providing this context [~adelapena] . Yes, this is what was also
our observation long ago when MIDRES config was created - it gives similar
timing for less credits/money in many cases
was (Author: e.dimitrova):
Thank you for providing this context [~adelapena] . Yes, this is what was also
our observation long ago when MIDRES config was created - it is gives similar
timing for less credits/money in many cases
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679303#comment-17679303
]
Ekaterina Dimitrova commented on CASSANDRA-18051:
-
Thank you for providing this context [~adelapena] . Yes, this is what was also
our observation long ago when MIDRES config was created - it is gives similar
timing for less credits/money in many cases
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679301#comment-17679301
]
Andres de la Peña commented on CASSANDRA-18051:
---
{quote}XLarge spends double the credits we spend for Large per minute
{quote}
One might think that the larger resources would finish in less minutes, but
that doesn't seem the case:
* This old [MIDRES
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2130/workflows/9df2d073-c26a-4750-82e4-8b6645f37f9c/jobs/16568/parallel-runs/1?filterBy=ALL]
of large dtests that I have stolen from [~e.dimitrova] seems to take ~93
minutes when adding the times of its four runners. It uses large containers.
* This [HIGHRES
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2129/workflows/b451fdf4-e643-42e9-86a4-f849e57c559f/jobs/16685/steps]
takes ~94 minutes to finish with its only runner. It uses xlarge containers.
Both runs contain 42 tests. I assume that the minutes we pay are the sum of
minutes we see on the GUI for every runner.
So it seems that the larger resources double the price while keeping the total
time unchanged.
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-18184) 'Maximum memory usage reached' chunk cache log message doesn't specify which cache is exhausted
[
https://issues.apache.org/jira/browse/CASSANDRA-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18184:
---
Description:
With Cassandra 4.0.x, we are seeing this cassandra.log message very frequently
on the majority of our Cassandra 4.0 clusters:
_[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
allocate chunk of 8.000MiB_
It took me several weeks to track down what it means, until I saw this start-up
message
_BufferPools.java:49 - Global buffer pool limit is 2.000GiB for chunk-cache
and 128.000MiB for networking_
This maximum memory usage warning would benefit from clarifying that its the
{*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted. With
'chunk cache' in both warning messages, they're too easily confused.
was:
With Cassandra 4.0.x, we are seeing this message very frequently on the
majority of our Cassandra 4.0 clusters:
_[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
allocate chunk of 8.000MiB_
It took me several weeks to track down what it means, until I saw this start-up
message
_BufferPools.java:49 - Global buffer pool limit is 2.000GiB for chunk-cache
and 128.000MiB for networking_
This maximum memory usage warning would benefit from clarifying that its the
{*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted. With
'chunk cache' in both warning messages, they're too easily confused.
> 'Maximum memory usage reached' chunk cache log message doesn't specify which
> cache is exhausted
> ---
>
> Key: CASSANDRA-18184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Priority: Normal
>
> With Cassandra 4.0.x, we are seeing this cassandra.log message very
> frequently on the majority of our Cassandra 4.0 clusters:
> _[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB_
> It took me several weeks to track down what it means, until I saw this
> start-up message
> _BufferPools.java:49 - Global buffer pool limit is 2.000GiB for
> chunk-cache and 128.000MiB for networking_
> This maximum memory usage warning would benefit from clarifying that its the
> {*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted.
> With 'chunk cache' in both warning messages, they're too easily confused.
>
--
This message was sent by Atlassian Jira
(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-18184) 'Maximum memory usage reached' chunk cache log message doesn't specify which cache is exhausted
[
https://issues.apache.org/jira/browse/CASSANDRA-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18184:
---
Summary: 'Maximum memory usage reached' chunk cache log message doesn't
specify which cache is exhausted (was: 'Maximum memory usage reached' chunk
cache message doesn't specify which cache is exhausted)
> 'Maximum memory usage reached' chunk cache log message doesn't specify which
> cache is exhausted
> ---
>
> Key: CASSANDRA-18184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Priority: Normal
>
> With Cassandra 4.0.x, we are seeing this message very frequently on the
> majority of our Cassandra 4.0 clusters:
> _[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB_
> It took me several weeks to track down what it means, until I saw this
> start-up message
> _BufferPools.java:49 - Global buffer pool limit is 2.000GiB for
> chunk-cache and 128.000MiB for networking_
> This maximum memory usage warning would benefit from clarifying that its the
> {*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted.
> With 'chunk cache' in both warning messages, they're too easily confused.
>
--
This message was sent by Atlassian Jira
(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-18184) 'Maximum memory usage reached' chunk cache message doesn't specify which cache is exhausted
[
https://issues.apache.org/jira/browse/CASSANDRA-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18184:
---
Summary: 'Maximum memory usage reached' chunk cache message doesn't specify
which cache is exhausted (was: Maximum memory usage reached chunk cache
message doesn't specify which cache is exhausted)
> 'Maximum memory usage reached' chunk cache message doesn't specify which
> cache is exhausted
> ---
>
> Key: CASSANDRA-18184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Priority: Normal
>
> With Cassandra 4.0.x, we are seeing this message very frequently on the
> majority of our Cassandra 4.0 clusters:
> _[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB_
> It took me several weeks to track down what it means, until I saw this
> start-up message
> _BufferPools.java:49 - Global buffer pool limit is 2.000GiB for
> chunk-cache and 128.000MiB for networking_
> This maximum memory usage warning would benefit from clarifying that its the
> {*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted.
> With 'chunk cache' in both warning messages, they're too easily confused.
>
--
This message was sent by Atlassian Jira
(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-18184) Maximum memory usage reached chunk cache message doesn't specify which cache is exhausted
[
https://issues.apache.org/jira/browse/CASSANDRA-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18184:
---
Description:
With Cassandra 4.0.x, we are seeing this message very frequently on the
majority of our Cassandra 4.0 clusters:
_[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
allocate chunk of 8.000MiB_
It took me several weeks to track down what it means, until I saw this start-up
message
_BufferPools.java:49 - Global buffer pool limit is 2.000GiB for chunk-cache
and 128.000MiB for networking_
This maximum memory usage warning would benefit from clarifying that its the
{*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted. With
'chunk cache' in both warning messages, they're too easily confused.
was:
With Cassandra 4.0.x, we are seeing this message very frequently on the
majority of our Cassandra 4.0 clusters:
_[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
allocate chunk of 8.000MiB_
It took me several weeks to track down what it means, until I saw this start-up
message
_BufferPools.java:49 - Global buffer pool limit is 2.000GiB for chunk-cache
and 128.000MiB for networking_
The maximum memory usage warning would benefit from clarifying that its the
{*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted. With
'chunk cache' in both warning messages, they're too easily confused.
> Maximum memory usage reached chunk cache message doesn't specify which cache
> is exhausted
> -
>
> Key: CASSANDRA-18184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Priority: Normal
>
> With Cassandra 4.0.x, we are seeing this message very frequently on the
> majority of our Cassandra 4.0 clusters:
> _[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB_
> It took me several weeks to track down what it means, until I saw this
> start-up message
> _BufferPools.java:49 - Global buffer pool limit is 2.000GiB for
> chunk-cache and 128.000MiB for networking_
> This maximum memory usage warning would benefit from clarifying that its the
> {*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted.
> With 'chunk cache' in both warning messages, they're too easily confused.
>
--
This message was sent by Atlassian Jira
(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-18184) Maximum memory usage reached chunk cache message doesn't specify which cache is exhausted
[
https://issues.apache.org/jira/browse/CASSANDRA-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18184:
---
Component/s: Observability/Logging
> Maximum memory usage reached chunk cache message doesn't specify which cache
> is exhausted
> -
>
> Key: CASSANDRA-18184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Priority: Normal
>
> With Cassandra 4.0.x, we are seeing this message very frequently on the
> majority of our Cassandra 4.0 clusters:
> _[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB_
> It took me several weeks to track down what it means, until I saw this
> start-up message
> _BufferPools.java:49 - Global buffer pool limit is 2.000GiB for
> chunk-cache and 128.000MiB for networking_
> The maximum memory usage warning would benefit from clarifying that its the
> {*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted.
> With 'chunk cache' in both warning messages, they're too easily confused.
>
--
This message was sent by Atlassian Jira
(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-18184) Maximum memory usage reached chunk cache message doesn't specify which cache is exhausted
[
https://issues.apache.org/jira/browse/CASSANDRA-18184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-18184:
---
Impacts: (was: None)
> Maximum memory usage reached chunk cache message doesn't specify which cache
> is exhausted
> -
>
> Key: CASSANDRA-18184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
>Reporter: Brad Schoening
>Priority: Normal
>
> With Cassandra 4.0.x, we are seeing this message very frequently on the
> majority of our Cassandra 4.0 clusters:
> _[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
> NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
> allocate chunk of 8.000MiB_
> It took me several weeks to track down what it means, until I saw this
> start-up message
> _BufferPools.java:49 - Global buffer pool limit is 2.000GiB for
> chunk-cache and 128.000MiB for networking_
> The maximum memory usage warning would benefit from clarifying that its the
> {*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted.
> With 'chunk cache' in both warning messages, they're too easily confused.
>
--
This message was sent by Atlassian Jira
(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-18184) Maximum memory usage reached chunk cache message doesn't specify which cache is exhausted
Brad Schoening created CASSANDRA-18184:
--
Summary: Maximum memory usage reached chunk cache message doesn't
specify which cache is exhausted
Key: CASSANDRA-18184
URL: https://issues.apache.org/jira/browse/CASSANDRA-18184
Project: Cassandra
Issue Type: Bug
Reporter: Brad Schoening
With Cassandra 4.0.x, we are seeing this message very frequently on the
majority of our Cassandra 4.0 clusters:
_[INFO ] [epollEventLoopGroup-5-3] cluster_id=99 ip_address=127.0.0.50
NoSpamLogger.java:92 - Maximum memory usage reached (128.000MiB), cannot
allocate chunk of 8.000MiB_
It took me several weeks to track down what it means, until I saw this start-up
message
_BufferPools.java:49 - Global buffer pool limit is 2.000GiB for chunk-cache
and 128.000MiB for networking_
The maximum memory usage warning would benefit from clarifying that its the
{*}network cache{*}, not the *off-heap chunk* *cache* which is exhausted. With
'chunk cache' in both warning messages, they're too easily confused.
--
This message was sent by Atlassian Jira
(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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679294#comment-17679294
]
Ekaterina Dimitrova commented on CASSANDRA-18051:
-
[https://circleci.com/product/features/resource-classes]
XLarge spends double the credits we spend for Large per minute
[~adelapena] has a valid point that plans for getting rid of the HIGHRES and
MIDRES config files in favor of one paid config are in place but I am afraid no
one has assigned that ticket and works on that actively yet.
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679289#comment-17679289
]
Andres de la Peña commented on CASSANDRA-18051:
---
{quote}People can run them with HIGHRES, locally, in Jenkins.
{quote}
I understand that there were plans to remove HIGHRES and rename the current
LOWRES and MIDRES to something like more related to their intended use. If we
actually remove HIGHRES there won't be an option to easily run them on Circle,
unless we can change them to use 2 DCs instead of 3. I don't see why those two
tests need the 3 DCs, but I might be missing something.
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679287#comment-17679287
]
Brandon Williams commented on CASSANDRA-11537:
--
Circle is running:
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/798/workflows/99acc46f-1ece-4798-b17d-ac98d203b208],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/798/workflows/ff5ac8b8-fc26-4891-9265-bc77009b49f4].
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678437#comment-17678437 ] Paulo Motta edited comment on CASSANDRA-16418 at 1/20/23 6:45 PM: -- Resubmitted CI after [test fix|https://github.com/linzuro/cassandra/commit/8de9c73d28291d2df67727ffcb7292f8c21b3442]: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2205|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/] (finished)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2206|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2206/] (finished)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2207|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/] (finished)| was (Author: paulo): Resubmitted CI after [test fix|https://github.com/linzuro/cassandra/commit/8de9c73d28291d2df67727ffcb7292f8c21b3442]: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2205|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/] (running)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2206|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2206/] (running)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2207|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/] (queued)| > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 3h > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (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-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679268#comment-17679268 ] Paulo Motta commented on CASSANDRA-16418: - Test failures look unrelated - for instance [test_decommissioned_node_cant_rejoin|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/testReport/junit/dtest.topology_test/TestTopology/test_decommissioned_node_cant_rejoin/] failed on 4.0 and [test_simultaneous_bootstrap|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/testReport/junit/dtest-novnode.bootstrap_test/TestBootstrap/test_simultaneous_bootstrap/] on trunk, but they don't seem to be at all related to this ticket. I ran these tests locally on the respective branches and they're passing. ok to merge [~smiklosovic]? > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 3h > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (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-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Nguyen updated CASSANDRA-11537:
---
Test and Documentation Plan: Unit tests (was: CHANGES.txt and unit tests)
Status: Patch Available (was: In Progress)
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Nguyen updated CASSANDRA-11537:
---
Status: In Progress (was: Changes Suggested)
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15048) Upgrade Netty to support TLS 1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679261#comment-17679261
]
Scott Guminy commented on CASSANDRA-15048:
--
Thanks. I was able to get it to start with {_}protocol: TLSv1.3{_}. Didn't
get any errors on startup. I scanned the port with a tool and it was able to
detect TLSv1.3 correctly. Seems like it might "just work".
> Upgrade Netty to support TLS 1.3
>
>
> Key: CASSANDRA-15048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15048
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Michaël Figuière
>Priority: Low
>
> TLS 1.3 support has been [added to Netty
> 4.1.31|https://netty.io/news/2018/10/30/4-1-31-Final.html]. As the Cassandra
> trunk is already relying on Netty 4.1.28, it would take a patch version
> upgrade and a \{{SslContext}} configuration change for Cassandra 4.0 to
> support TLS 1.3.
--
This message was sent by Atlassian Jira
(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-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679262#comment-17679262
]
William Nguyen commented on CASSANDRA-11537:
[https://github.com/apache/cassandra/pull/2060|https://github.com/apache/cassandra/pull/2060.]
Changed the approach because we didn't have permission for
{{StorageService.isInitialized,}} which is why the jmx auth test failed. The
new approach finishes registering the mbeans in {{StorageService}} at the end
of its initialization. This will cause an {{InstanceNotFoundException}} when
the nodetool command is issued and the server isn't ready. I catch and convert
this exception to an {{{}IllegalArgumentException{}}}.
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17112: -- Status: Ready to Commit (was: Changes Suggested) +1 from Benedict > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 7h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679246#comment-17679246
]
Michael Semb Wever commented on CASSANDRA-18051:
How much is the additional cost of running "Large DTests" in xlarge instead of
large ?
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679241#comment-17679241
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
FYI - just for completeness, posting also here. When I started working on
CASSANDRA-18139 I noticed the change is not the output, units are binary since
Cassandra 3.6, CASSANDRA-9692. The change done here was to the constants names.
More info - CASSANDRA-18139
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1-alpha1, 4.1
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(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-18139) Revert changes to units output in FileUtils#stringifyFileSize post CASSANDRA-15234
[ https://issues.apache.org/jira/browse/CASSANDRA-18139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679240#comment-17679240 ] Ekaterina Dimitrova commented on CASSANDRA-18139: - Oh wait, we didn't change the printed units in CASSANDRA-15234! They were already printed as TiB, MiB, etc changed in CASSANDRA-9692. Those are printed that way since 3.6 We changed in [this|https://github.com/apache/cassandra/commit/1315d0c96f4625a76296f58d431f97669e5178c2] and [this|https://github.com/apache/cassandra/commit/23138252f20891c26a3692664c6affaf99e86541] commits the constants ONE_KB to ONE_KIB etc. I do not believe that this is considered a breaking change, is it? We didn't change the nodetool output? [~ifesdjeen] did you actually refer to the constants? Is FileUtils considered API that will be used by tools? Is this documented? What do I miss? > Revert changes to units output in FileUtils#stringifyFileSize post > CASSANDRA-15234 > -- > > Key: CASSANDRA-18139 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18139 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > As discussed in CASSANDRA-15234, FileUtils#stringifyFileSize is used in > nodetool output which can break people parsing the nodetool output -- This message was sent by Atlassian Jira (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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679238#comment-17679238
]
Michael Semb Wever commented on CASSANDRA-18088:
Docker images are getting published…
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.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-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679232#comment-17679232
]
Ekaterina Dimitrova commented on CASSANDRA-18051:
-
I would like to suggest we add a message in DTests for those two to be logged
in case someone is using MIDRES in CircleCI and they fail, so they know the
reason and move on. People can run them with HIGHRES, locally, in Jenkins.
Raising the default MIDRES resources only for two tests is too expensive in my
opinion.
It might be that less data centers testing is completely harmless but I do not
believe people have the time now to look more in details in to that and
considering that those tests were added to improve our coverage on critical
path, I think it is best just to leave them alone for now.
[~adelapena] , [~mck] any thoughts?
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-18148: Assignee: Brandon Williams > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- This message was sent by Atlassian Jira (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-18148) netty-all vulnerability: CVE-2022-41881
[ https://issues.apache.org/jira/browse/CASSANDRA-18148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679228#comment-17679228 ] Brandon Williams commented on CASSANDRA-18148: -- Patches to suppress: ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/795/workflows/e3fcd4c8-501a-4baf-84ea-bd01f5ee344a]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/793/workflows/b360fdf0-837e-440e-b22a-2891c74a6545]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/797/workflows/1a5ba6cb-be5e-4291-a55c-8fa86950b95d], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/797/workflows/3993a7a6-65be-4ca8-8a5e-7d3d29c147e8]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/796/workflows/a96803ec-1378-4969-af4f-fdcc1906ae93], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/796/workflows/598c-3449-418e-b276-115eea564165]| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18148-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/794/workflows/f5fe2081-70b4-4674-b39e-11fcf5aced13], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/794/workflows/e590663b-bf82-4704-8d5a-45ccbe3ee45c]| > netty-all vulnerability: CVE-2022-41881 > --- > > Key: CASSANDRA-18148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18148 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This is showing in the OWASP scan. -- This message was sent by Atlassian Jira (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-18181) Fix tests post JDK-8210522
[
https://issues.apache.org/jira/browse/CASSANDRA-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679225#comment-17679225
]
Ekaterina Dimitrova edited comment on CASSANDRA-18181 at 1/20/23 4:51 PM:
--
h5. This affects Java distributed tests,
[Instance.startup|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/impl/Instance.java#L653]
and some other tests:
* ConnectionTest
* ProxyHandlerConnectionsTest
* ConnectionBurnTestTest
* FramingTest
* MessageSerializationPropertyTest
* MessageTest
* OutboundConnectionsTest
* ProxyHandlerConnectionsTest
* DriverBurnTests
* SimpleClientBurnTest
* MessagePayloadTest
The patch is posted
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/a06dbb6b8f90d5b92dfa6ebffd276a218fae57fe]
The solution used is similar to what other projects did, for example HBase.
It was already discussed in CASSANDRA-17178
Pushed Jenkins CI run (to cover J8+J11), the job is in the queue as there are
already 2 jobs running in Jenkins dev.
I will check back and post a link later today to the trunk J8+J11 Jenkins CI
run but I am fairly confident the run will be fine as I ran some of the tests
locally and I was running this patch also with JDK17 for some time, too. Here
is the run with J17 branch
[J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2182/workflows/9ca49487-937a-4c72-bc78-4fbefe23db76]
and
[J17|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2182/workflows/e3dc630b-b7a4-4f5b-8f29-489bf43ad90f]
there are certain failures but those are not related to what we address here.
While this patch is not needed for J8+J11 It is a preparation for when we
switch to J11+J17. Trying to push in everything we can until CASSANDRA-17281
and a few other things are disentangled
was (Author: e.dimitrova):
h5. This affects Java distributed tests, Instance.startup and some other tests:
* ConnectionTest
* ProxyHandlerConnectionsTest
* ConnectionBurnTestTest
* FramingTest
* MessageSerializationPropertyTest
* MessageTest
* OutboundConnectionsTest
* ProxyHandlerConnectionsTest
* DriverBurnTests
* SimpleClientBurnTest
* MessagePayloadTest
The patch is posted
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/a06dbb6b8f90d5b92dfa6ebffd276a218fae57fe]
The solution used is similar to what other projects did, for example HBase.
It was already discussed in CASSANDRA-17178
Pushed Jenkins CI run (to cover J8+J11), the job is in the queue as there are
already 2 jobs running in Jenkins dev.
I will check back and post a link later today to the trunk J8+J11 Jenkins CI
run but I am fairly confident the run will be fine as I ran some of the tests
locally and I was running this patch also with JDK17 for some time, too. Here
is the run with J17 branch
[J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2182/workflows/9ca49487-937a-4c72-bc78-4fbefe23db76]
and
[J17|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2182/workflows/e3dc630b-b7a4-4f5b-8f29-489bf43ad90f]
there are certain failures but those are not related to what we address here.
While this patch is not needed for J8+J11 It is a preparation for when we
switch to J11+J17. Trying to push in everything we can until CASSANDRA-17281
and a few other things are disentangled
> Fix tests post JDK-8210522
> --
>
> Key: CASSANDRA-18181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18181
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
>
> From JDK-8210522:
> {code:java}
> Core reflection has a filtering mechanism to hide security and integrity
> sensitive fields and methods from Class getXXXField(s) and getXXXMethod(s).
> The filtering mechanism has been used for several releases to hide security
> sensitive fields such as System.security and Class.classLoader.
> This CSR proposes to extend the filters to hide fields from a number of
> highly security sensitive classes in java.lang.reflect and java.lang.invoke.
> {code}
> We are using at a few places in our tests
> {code:java}
> Field.class.getDeclaredField("modifiers");{code}
> This breaks as expected when tests are run with JDK17, example:
>
> {code:java}
> java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:79)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>
[jira] [Commented] (CASSANDRA-18181) Fix tests post JDK-8210522
[
https://issues.apache.org/jira/browse/CASSANDRA-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679225#comment-17679225
]
Ekaterina Dimitrova commented on CASSANDRA-18181:
-
h5. This affects Java distributed tests, Instance.startup and some other tests:
* ConnectionTest
* ProxyHandlerConnectionsTest
* ConnectionBurnTestTest
* FramingTest
* MessageSerializationPropertyTest
* MessageTest
* OutboundConnectionsTest
* ProxyHandlerConnectionsTest
* DriverBurnTests
* SimpleClientBurnTest
* MessagePayloadTest
The patch is posted
[here|https://github.com/ekaterinadimitrova2/cassandra/commit/a06dbb6b8f90d5b92dfa6ebffd276a218fae57fe]
The solution used is similar to what other projects did, for example HBase.
It was already discussed in CASSANDRA-17178
Pushed Jenkins CI run (to cover J8+J11), the job is in the queue as there are
already 2 jobs running in Jenkins dev.
I will check back and post a link later today to the trunk J8+J11 Jenkins CI
run but I am fairly confident the run will be fine as I ran some of the tests
locally and I was running this patch also with JDK17 for some time, too. Here
is the run with J17 branch
[J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2182/workflows/9ca49487-937a-4c72-bc78-4fbefe23db76]
and
[J17|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2182/workflows/e3dc630b-b7a4-4f5b-8f29-489bf43ad90f]
there are certain failures but those are not related to what we address here.
While this patch is not needed for J8+J11 It is a preparation for when we
switch to J11+J17. Trying to push in everything we can until CASSANDRA-17281
and a few other things are disentangled
> Fix tests post JDK-8210522
> --
>
> Key: CASSANDRA-18181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18181
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
>
> From JDK-8210522:
> {code:java}
> Core reflection has a filtering mechanism to hide security and integrity
> sensitive fields and methods from Class getXXXField(s) and getXXXMethod(s).
> The filtering mechanism has been used for several releases to hide security
> sensitive fields such as System.security and Class.classLoader.
> This CSR proposes to extend the filters to hide fields from a number of
> highly security sensitive classes in java.lang.reflect and java.lang.invoke.
> {code}
> We are using at a few places in our tests
> {code:java}
> Field.class.getDeclaredField("modifiers");{code}
> This breaks as expected when tests are run with JDK17, example:
>
> {code:java}
> java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:79)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NoSuchFieldException: modifiers at
> java.base/java.lang.Class.getDeclaredField(Class.java:2610)
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:70)
>
> ... 15 more{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-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679224#comment-17679224 ] Brandon Williams commented on CASSANDRA-18150: -- I'm not sure why SafeConstructor breaks JMXTool or what the best way to handle that is... [~dcapwell] can you advise? > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (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-18142) CEP-15: (Accord/C*) Shard CommandStores by contiguous ranges
[ https://issues.apache.org/jira/browse/CASSANDRA-18142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18142: -- Authors: Benedict Elliott Smith Reviewers: Aleksey Yeschenko > CEP-15: (Accord/C*) Shard CommandStores by contiguous ranges > > > Key: CASSANDRA-18142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18142 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > For efficiency and simplicity, nodes should internally shard on contiguous > ranges. -- This message was sent by Atlassian Jira (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-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679206#comment-17679206
]
Brandon Williams commented on CASSANDRA-18183:
--
Ah, I see, that makes sense, thanks. +1
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an opportunistic fix
> really.
--
This message was sent by Atlassian Jira
(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-18172) CEP-15: (Accord/C*) Refactor Timestamp/TxnId
[ https://issues.apache.org/jira/browse/CASSANDRA-18172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-18172: -- Authors: Benedict Elliott Smith Reviewers: Aleksey Yeschenko > CEP-15: (Accord/C*) Refactor Timestamp/TxnId > > > Key: CASSANDRA-18172 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18172 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > Reduce the amount of storage required for Timestamp and TxnId by compressing > epoch to 48 bits, and real/logical to a single 64-bit HLC, while also > supporting flag carrier bits for communicating protocol state information. -- This message was sent by Atlassian Jira (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-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679203#comment-17679203
]
Stefan Miklosovic commented on CASSANDRA-18183:
---
I mentioned that at the bottom in the description:
To have the very same experience, I am also creating a symlink
ln -s /tmp/cassandra/trunk/build build
so "cd build / ls build" in the root of the repository will take me to ramdisk.
The problem with this is that there is "build/" in .gitignore but not "build"
(as file) so the repository is in dirty state. I suggest to add "build" to
.gitignore as part of this PR as that is just an opportunistic fix really.
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an opportunistic fix
> really.
--
This message was sent by Atlassian Jira
(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-18182) Cython not tested on 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18182: Resolution: Duplicate Status: Resolved (was: Open) > Cython not tested on 4.0 > > > Key: CASSANDRA-18182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18182 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > We [test > cython|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L334] > in 4.1 and trunk, but it is missing on 4.0 which has the same cython > configuration. -- This message was sent by Atlassian Jira (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-18182) Cython not tested on 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679201#comment-17679201 ] Ekaterina Dimitrova commented on CASSANDRA-18182: - Yes, I will, thanks. I will link and close, thanks > Cython not tested on 4.0 > > > Key: CASSANDRA-18182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18182 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > We [test > cython|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L334] > in 4.1 and trunk, but it is missing on 4.0 which has the same cython > configuration. -- This message was sent by Atlassian Jira (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-15048) Upgrade Netty to support TLS 1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679199#comment-17679199
]
Brandon Williams commented on CASSANDRA-15048:
--
If it works, it's not being tested right now.
> Upgrade Netty to support TLS 1.3
>
>
> Key: CASSANDRA-15048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15048
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Michaël Figuière
>Priority: Low
>
> TLS 1.3 support has been [added to Netty
> 4.1.31|https://netty.io/news/2018/10/30/4-1-31-Final.html]. As the Cassandra
> trunk is already relying on Netty 4.1.28, it would take a patch version
> upgrade and a \{{SslContext}} configuration change for Cassandra 4.0 to
> support TLS 1.3.
--
This message was sent by Atlassian Jira
(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-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679193#comment-17679193
]
Brandon Williams commented on CASSANDRA-18183:
--
bq. do you indeed want me to run all 5 branches for this?
That's overkill for a simple build change like this. I am mostly +1, but why
the .gitignore modification?
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an opportunistic fix
> really.
--
This message was sent by Atlassian Jira
(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-18182) Cython not tested on 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679190#comment-17679190 ] Brandon Williams commented on CASSANDRA-18182: -- Yes, I meant in circle. bq. There is a ticket I am finishing for pre-4.1 If you plan to handle it there, feel free to link and close this as duplicate. > Cython not tested on 4.0 > > > Key: CASSANDRA-18182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18182 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > We [test > cython|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L334] > in 4.1 and trunk, but it is missing on 4.0 which has the same cython > configuration. -- This message was sent by Atlassian Jira (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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679187#comment-17679187 ] Mike Adamson commented on CASSANDRA-18058: -- [~adelapena] Thanks for the information about the CI setup. I will update my CASSANDRA-18062 branch to use these settings. > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: NA > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- This message was sent by Atlassian Jira (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-15048) Upgrade Netty to support TLS 1.3
[
https://issues.apache.org/jira/browse/CASSANDRA-15048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679177#comment-17679177
]
Scott Guminy commented on CASSANDRA-15048:
--
Soon we will have a mandate to support TLS 1.3. I see the Netty has been
upgraded to 4.1.58 in Cassandra 4.0.7. Does Cassandra officially support TLS
1.3 at this point?
> Upgrade Netty to support TLS 1.3
>
>
> Key: CASSANDRA-15048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15048
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Michaël Figuière
>Priority: Low
>
> TLS 1.3 support has been [added to Netty
> 4.1.31|https://netty.io/news/2018/10/30/4-1-31-Final.html]. As the Cassandra
> trunk is already relying on Netty 4.1.28, it would take a patch version
> upgrade and a \{{SslContext}} configuration change for Cassandra 4.0 to
> support TLS 1.3.
--
This message was sent by Atlassian Jira
(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-18088) cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-18088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679168#comment-17679168
]
Ekaterina Dimitrova commented on CASSANDRA-18088:
-
Sure, but I think [~mck] is already on it based on ASF Slack chat I saw. Still,
let me know if you need me for anything. Happy to help
> cqlsh - module 're' has no attribute 'sre_parse' - with Python 3.11
> ---
>
> Key: CASSANDRA-18088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18088
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Aaron Ploetz
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> User reported an error with cqlsh (Cassandra 4.0.7) on Stack Overflow:
> [https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error|https://stackoverflow.com/questions/74673247/cannot-able-to-run-cqlsh-due-to-python-attribute-error?noredirect=1#comment131807816_74673247]
>
> Found out that the user was using Python 3.11, and I was able to reproduce it
> with that.
> {{% python3.11 bin/cqlsh.py}}
> {{Traceback (most recent call last):}}
> {{ File "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/cqlsh.py", line
> 159, in }}
> {{ from cqlshlib import cql3handling, cqlhandling, pylexotron,
> sslhandling, cqlshhandling}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cql3handling.py",
> line 19, in }}
> {{ from cqlshlib.cqlhandling import CqlParsingRuleSet, Hint}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/cqlhandling.py",
> line 23, in }}
> {{ from cqlshlib import pylexotron, util}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 342, in }}
> {{ class ParsingRuleSet:}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/pylexotron.py",
> line 343, in ParsingRuleSet}}
> {{ RuleSpecScanner = SaferScanner([}}
> {{ ^^}}
> {{ File
> "/Users/aaronploetz/local/apache-cassandra-4.0.7/bin/../pylib/cqlshlib/saferscanner.py",
> line 91, in _{_}init{_}_}}
> {{ s = re.sre_parse.State()}}
> {{ }}
> {{AttributeError: module 're' has no attribute 'sre_parse'}}
> Appears to be something specific (again) with Python's synchronizing regex
> engine (SRE). Works fine with Python 3.10, so there may have been a(nother)
> breaking change in that the re module with 3.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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679154#comment-17679154
]
maxwellguo commented on CASSANDRA-17698:
[~adelapena] In that way，should we separate this issue to two？one for what you
said return a special string do not require deserialization ，one is what i have
done that is better to fix in 4.2/5.0
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {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-18182) Cython not tested on 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679148#comment-17679148 ] Ekaterina Dimitrova commented on CASSANDRA-18182: - You mean in CircleCI? There is a ticket I am finishing for pre-4.1 > Cython not tested on 4.0 > > > Key: CASSANDRA-18182 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18182 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > > We [test > cython|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml#L334] > in 4.1 and trunk, but it is missing on 4.0 which has the same cython > configuration. -- This message was sent by Atlassian Jira (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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679145#comment-17679145
]
Andres de la Peña commented on CASSANDRA-17698:
---
[~blambov] Making it a 4.2/5.0-only fix makes sense to me.
As for previous branches, I wonder whether it would make sense to make
{{PartitionerDefinedOrder#toJSONString(ByteBuffer, ProtocolVersion)}} return a
special string that doesn't require deserialization, like the hex
representation of the {{{}ByteBuffer{}}}. That at least would print something
without breaking the rest of the json conversion, and it would be possible to
somewhat use {{sstabledump}} on 2i sstables. The problem is that the returned
string could be confused with the real deserialized value of a text key, and it
might not play well with {{fromJson}} methods.
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {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-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679141#comment-17679141
]
Stefan Miklosovic commented on CASSANDRA-18183:
---
[~mck] [~brandon.williams] would you take a look? I am running 3.0 build, do
you indeed want me to run all 5 branches for this? PRs for other branches are
exactly same.
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an opportunistic fix
> really.
--
This message was sent by Atlassian Jira
(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-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679139#comment-17679139
]
Andres de la Peña edited comment on CASSANDRA-17507 at 1/20/23 1:06 PM:
Oh, right, it's a typo, the last 4.0 affected version is 4.0.7. Just fixed it,
thanks!
was (Author: adelapena):
Oh, right, it's a typo, the last 4.0 affected version is 4.0.7.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679139#comment-17679139
]
Andres de la Peña commented on CASSANDRA-17507:
---
Oh, right, it's a typo, the last 4.0 affected version is 4.0.7.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Updated] (CASSANDRA-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18183:
--
Test and Documentation Plan: successful CI, ant artifacts on different
build propreties will not fail the build
Status: Patch Available (was: Open)
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an opportunistic fix
> really.
--
This message was sent by Atlassian Jira
(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-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679130#comment-17679130
]
Stefan Miklosovic edited comment on CASSANDRA-18183 at 1/20/23 1:04 PM:
3.0 [https://github.com/apache/cassandra/pull/2106]
3.0 CI
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2208/]
3.11 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-18183-3.11]
4.0 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-18183-4.0]
4.1 [https://github.com/instaclustr/cassandra/tree/CASSANDRA-18183-4.1]
trunk [https://github.com/instaclustr/cassandra/tree/CASSANDRA-18183-trunk]
was (Author: smiklosovic):
3.0 [https://github.com/apache/cassandra/pull/2106]
3.0 CI
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2208/]
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an opportunistic fix
> really.
--
This message was sent by Atlassian Jira
(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-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679136#comment-17679136
]
Brandon Williams commented on CASSANDRA-17507:
--
bq. or 4.0.0-4.0.3
Is 4.0.3 correct? I don't understand the significance if we are putting the
fix in 4.0.8.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional
[jira] [Commented] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679135#comment-17679135
]
Andres de la Peña commented on CASSANDRA-17507:
---
Makes sense, thanks for the feedback. I have added that entry on
{{{}NEWS.txt{}}}, it says:
{quote}All previous versions of 4.x contained a mistake on the implementation
of the old CQL native protocol v3. That mistake produced issues when paging
over tables with compact storage and a single clustering column during rolling
upgrades involving 3.x and 4.x nodes. The fix for that issue makes that it can
now appear during rolling upgrades from 4.1.0 or 4.0.0-4.0.3. If that your
case, please use protocol v4 or higher in your driver. See CASSANDRA-17507 for
further details.
{quote}
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
>
[jira] [Updated] (CASSANDRA-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18183:
--
Description:
I detected this when I was trying to put my build dir to ramdisk. I have plenty
of RAM available on my workstation (64GB) and I was thinking about moving
"build" dir to ramdisk so I could make it faster a little bit and also spare
some write cycles to ssd. It can look like irrelevant improvement but I think
that if devs are building the project repeatedly times and times again, this
can easily add up.
{code:java}
mkdir /tmp/cassandra
# in /etc/fstab
tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777 0 0
# then sudo mount -a
# I have worktree setup so the build for each branch will end up in different
dir:
# mkdir -p
/tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
{code}
Then in build.properties for each respective branch:
{code:java}
ant.gen-doc.skip: true
build.dir: /tmp/cassandra/trunk/build
build.dir.lib: /tmp/cassandra/trunk/build/lib
{code}
The problem with this is that it fails on rat, because there is not "build.dir"
property used, it is hardcoded to "build" but there is not anything to rat on
so it will hang.
To have the very same experience, I am also creating a symlink
{code}
ln -s /tmp/cassandra/trunk/build build
{code}
so "cd build / ls build" in the root of the repository will take me to ramdisk.
The problem with this is that there is "build/" in .gitignore but not "build"
(as file) so the repository is in dirty state. I suggest to add "build" to
.gitignore as part of this PR as that is just an opportunistic fix really.
was:
I detected this when I was trying to put my build dir to ramdisk. I have plenty
of RAM available on my workstation (64GB) and I was thinking about moving
"build" dir to ramdisk so I could make it faster a little bit and also spare
some write cycles to ssd. It can look like irrelevant improvement but I think
that if devs are building the project repeatedly times and times again, this
can easily add up.
{code:java}
mkdir /tmp/cassandra
# in /etc/fstab
tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777 0 0
# then sudo mount -a
# I have worktree setup so the build for each branch will end up in different
dir:
# mkdir -p
/tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
{code}
Then in build.properties for each respective branch:
{code:java}
ant.gen-doc.skip: true
build.dir: /tmp/cassandra/trunk/build
build.dir.lib: /tmp/cassandra/trunk/build/lib
{code}
The problem with this is that it fails on rat, because there is not "build.dir"
property used, it is hardcoded to "build" but there is not anything to rat on
so it will hang.
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
> To have the very same experience, I am also creating a symlink
>
> {code}
> ln -s /tmp/cassandra/trunk/build build
> {code}
> so "cd build / ls build" in the root of the repository will take me to
> ramdisk. The problem with this is that there is "build/" in .gitignore but
> not "build" (as file) so the repository is in dirty state. I suggest to add
> "build" to .gitignore as part of this PR as that is just an
[jira] [Comment Edited] (CASSANDRA-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679130#comment-17679130
]
Stefan Miklosovic edited comment on CASSANDRA-18183 at 1/20/23 12:28 PM:
-
3.0 [https://github.com/apache/cassandra/pull/2106]
3.0 CI
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2208/]
was (Author: smiklosovic):
https://github.com/apache/cassandra/pull/2106
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
--
This message was sent by Atlassian Jira
(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-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18183:
--
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: Adhoc Test
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
4.x
Severity: Low
Assignee: Stefan Miklosovic
Status: Open (was: Triage Needed)
https://github.com/apache/cassandra/pull/2106
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
--
This message was sent by Atlassian Jira
(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-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18027: --- Fix Version/s: 4.1.1 4.2 (was: 4.x) (was: 4.1.x) Source Control Link: https://github.com/apache/cassandra/commit/7c86e18baf10b3cf6c8f06ee9f1e27d2e21acf78 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [7c86e18baf10b3cf6c8f06ee9f1e27d2e21acf78|https://github.com/apache/cassandra/commit/7c86e18baf10b3cf6c8f06ee9f1e27d2e21acf78]. > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.1, 4.2 > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian 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] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8413e9d6fdd114667deb81ea1d21d6eb486cb635 Merge: 45e00ea92f 7c86e18baf Author: Mick Semb Wever AuthorDate: Fri Jan 20 13:13:54 2023 +0100 Merge branch 'cassandra-4.1' into trunk * cassandra-4.1: Update G1GC settings, and make it default in trunk CHANGES.txt | 1 + conf/jvm11-server.options | 32 +--- conf/jvm8-server.options | 38 -- 3 files changed, 38 insertions(+), 33 deletions(-) diff --cc CHANGES.txt index 5bcf25667c,1352d00b26..36934c6454 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,102 -1,4 +1,103 @@@ -4.1.1 +4.2 ++ * Use G1GC by default, and update default G1GC settings (CASSANDRA-18027) + * SimpleSeedProvider can resolve multiple IP addresses per DNS record (CASSANDRA-14361) + * Remove mocking in InternalNodeProbe spying on StorageServiceMBean (CASSANDRA-18152) + * Add compaction_properties column to system.compaction_history table and nodetool compactionhistory command (CASSANDRA-18061) + * Remove ProtocolVersion entirely from the CollectionSerializer ecosystem (CASSANDRA-18114) + * Fix serialization error in new getsstables --show-levels option (CASSANDRA-18140) + * Use checked casts when reading vints as ints (CASSANDRA-18099) + * Add Mutation Serialization Caching (CASSANDRA-17998) + * Only reload compaction strategies if disk boundaries change (CASSANDRA-17874) + * CEP-10: Simulator Java11 Support (CASSANDRA-17178) + * Set the major compaction type correctly for compactionstats (CASSANDRA-18055) + * Print exception message without stacktrace when nodetool commands fail on probe.getOwnershipWithPort() (CASSANDRA-18079) + * Add option to print level in nodetool getsstables output (CASSANDRA-18023) + * Implement a guardrail for not having zero default_time_to_live on tables with TWCS (CASSANDRA-18042) + * Add CQL scalar functions for collection aggregation (CASSANDRA-18060) + * Make cassandra.replayList property for CommitLogReplayer possible to react on keyspaces only (CASSANDRA-18044) + * Add Mathematical functions (CASSANDRA-17221) + * Make incremental backup configurable per table (CASSANDRA-15402) + * Change shebangs of Python scripts to resolve Python 3 from env command (CASSANDRA-17832) + * Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING (CASSANDRA-17967) + * Add support for CQL functions on collections, tuples and UDTs (CASSANDRA-17811) + * Add flag to exclude nodes from local DC when running nodetool rebuild (CASSANDRA-17870) + * Adding endpoint verification option to client_encryption_options (CASSANDRA-18034) + * Replace 'wcwidth.py' with pypi module (CASSANDRA-17287) + * Add nodetool forcecompact to remove tombstoned or ttl'd data ignoring GC grace for given table and partition keys (CASSANDRA-17711) + * Offer IF (NOT) EXISTS in cqlsh completion for CREATE TYPE, DROP TYPE, CREATE ROLE and DROP ROLE (CASSANDRA-16640) + * Nodetool bootstrap resume will now return an error if the operation fails (CASSANDRA-16491) + * Disable resumable bootstrap by default (CASSANDRA-17679) + * 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) + * Further improves precision of memtable heap tracking (CASSANDRA-17240) + * Fix formatting of metrics documentation (CASSANDRA-17961) + * Keep sstable level when streaming for decommission and move (CASSANDRA-17969) + * Add Unavailables metric for CASWrite in the docs (CASSANDRA-16357) + * Make Cassandra logs able to be viewed in the virtual table system_views.system_logs (CASSANDRA-17946) + * IllegalArgumentException in Gossiper#order due to concurrent mutations to elements being applied (CASSANDRA-17908) + * Include estimated active compaction remaining write size when starting a new compaction (CASSANDRA-17931) + * Mixed mode support for internode authentication during TLS upgrades (CASSANDRA-17923) + * Revert Mockito downgrade from CASSANDRA-17750 (CASSANDRA-17496) + * Add --older-than and --older-than-timestamp options for nodetool clearsnapshots (CASSANDRA-16860) + * Fix "open RT bound as its last item" exception (CASSANDRA-17810) + * Fix leak of non-standard Java types in JMX MBeans `org.apache.cassandra.db:type=StorageService` + and `org.apache.cassandra.db:type=RepairService` as clients using JMX cannot handle them. More details in NEWS.txt (CASSANDRA-17668) + * Deprecate Throwables.propagate usage (CASSANDRA-14218) + * Allow disabling hotness persistence for high sstable counts (CASSANDRA-17868) + * Prevent
[cassandra] branch cassandra-4.1 updated: Update G1GC settings, and make it default in trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.1 by this push: new 7c86e18baf Update G1GC settings, and make it default in trunk 7c86e18baf is described below commit 7c86e18baf10b3cf6c8f06ee9f1e27d2e21acf78 Author: Mick Semb Wever AuthorDate: Sat Jan 14 00:25:23 2023 +0100 Update G1GC settings, and make it default in trunk patch by Mick Semb Wever; patch by Anthony Grasso, Brandon Williams, Derek Chen-Becker, Jeremiah Jordan, Jon Haddad, Josh McKenzie for CASSANDRA-18027 --- NEWS.txt | 12 conf/jvm11-server.options | 4 +++- conf/jvm8-server.options | 4 +++- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS.txt b/NEWS.txt index b48f065f0d..c1dfbd8127 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -51,6 +51,18 @@ restore snapshots created with the previous major version using the 'sstableloader' tool. You can upgrade the file format of your snapshots using the provided 'sstableupgrade' tool. + +4.1.1 +=== + +G1GC Recommended + +- The G1 settings in jvm8-server.options and jvm11-server.options are updated according to broad feedback + and testing. The G1 settings remain commented out by default in 4.1.x. It is recommended to switch + to G1 for performance and for simpler GC tuning. CMS is already deprecated in JDK9, and the next major + release of Cassandra makes G1 the default configuration. + + 4.1 === diff --git a/conf/jvm11-server.options b/conf/jvm11-server.options index 7e78467853..1fc3503adb 100644 --- a/conf/jvm11-server.options +++ b/conf/jvm11-server.options @@ -29,6 +29,8 @@ ## Use the Hotspot garbage-first collector. #-XX:+UseG1GC #-XX:+ParallelRefProcEnabled +#-XX:MaxTenuringThreshold=1 +#-XX:G1HeapRegionSize=16m # ## Have the JVM do less remembered set work during STW, instead @@ -38,7 +40,7 @@ ## Main G1GC tunable: lowering the pause target will lower throughput and vise versa. ## 200ms is the JVM default and lowest viable setting ## 1000ms increases throughput. Keep it smaller than the timeouts in cassandra.yaml. -#-XX:MaxGCPauseMillis=500 +#-XX:MaxGCPauseMillis=300 ## Optional G1 Settings # Save CPU time on large (>= 16GB) heaps by delaying region scanning diff --git a/conf/jvm8-server.options b/conf/jvm8-server.options index 6214669eab..ba800db4b4 100644 --- a/conf/jvm8-server.options +++ b/conf/jvm8-server.options @@ -35,6 +35,8 @@ ## Use the Hotspot garbage-first collector. #-XX:+UseG1GC #-XX:+ParallelRefProcEnabled +#-XX:MaxTenuringThreshold=1 +#-XX:G1HeapRegionSize=16m # ## Have the JVM do less remembered set work during STW, instead @@ -44,7 +46,7 @@ ## Main G1GC tunable: lowering the pause target will lower throughput and vise versa. ## 200ms is the JVM default and lowest viable setting ## 1000ms increases throughput. Keep it smaller than the timeouts in cassandra.yaml. -#-XX:MaxGCPauseMillis=500 +#-XX:MaxGCPauseMillis=300 ## Optional G1 Settings # Save CPU time on large (>= 16GB) heaps by delaying region scanning - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (45e00ea92f -> 8413e9d6fd)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 45e00ea92f Merge branch 'cassandra-4.1' into trunk new 7c86e18baf Update G1GC settings, and make it default in trunk new 8413e9d6fd Merge branch 'cassandra-4.1' into trunk The 2 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: CHANGES.txt | 1 + conf/jvm11-server.options | 32 +--- conf/jvm8-server.options | 38 -- 3 files changed, 38 insertions(+), 33 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18183) rat targets do not adhere to build.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18183:
--
Description:
I detected this when I was trying to put my build dir to ramdisk. I have plenty
of RAM available on my workstation (64GB) and I was thinking about moving
"build" dir to ramdisk so I could make it faster a little bit and also spare
some write cycles to ssd. It can look like irrelevant improvement but I think
that if devs are building the project repeatedly times and times again, this
can easily add up.
{code:java}
mkdir /tmp/cassandra
# in /etc/fstab
tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777 0 0
# then sudo mount -a
# I have worktree setup so the build for each branch will end up in different
dir:
# mkdir -p
/tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
{code}
Then in build.properties for each respective branch:
{code:java}
ant.gen-doc.skip: true
build.dir: /tmp/cassandra/trunk/build
build.dir.lib: /tmp/cassandra/trunk/build/lib
{code}
The problem with this is that it fails on rat, because there is not "build.dir"
property used, it is hardcoded to "build" but there is not anything to rat on
so it will hang.
was:
I detected this when I was trying to put my build dir to ramdisk. I have plenty
of RAM available on my workstation (64GB) and I was thinking about moving
"build" dir to ramdisk so I could make it faster a little bit and also spare
some write cycles to ssd. It can look like irrelevant improvement but I think
that if devs are build the project repeatedly times and times again, this can
easily add up.
{code}
mkdir /tmp/cassandra
# in /etc/fstab
tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777 0 0
# then sudo mount -a
# I have worktree setup so the build for each branch will end up in different
dir:
# mkdir -p
/tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
{code}
Then in build.properties for each respective branch:
{code}
ant.gen-doc.skip: true
build.dir: /tmp/cassandra/trunk/build
build.dir.lib: /tmp/cassandra/trunk/build/lib
{code}
The problem with this is that it fails on rat, because there is not "build.dir"
property used, it is hardcoded to "build" but there is not anything to rat on
so it will hang.
> rat targets do not adhere to build.dir property
> ---
>
> Key: CASSANDRA-18183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> I detected this when I was trying to put my build dir to ramdisk. I have
> plenty of RAM available on my workstation (64GB) and I was thinking about
> moving "build" dir to ramdisk so I could make it faster a little bit and also
> spare some write cycles to ssd. It can look like irrelevant improvement but I
> think that if devs are building the project repeatedly times and times again,
> this can easily add up.
> {code:java}
> mkdir /tmp/cassandra
> # in /etc/fstab
> tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777
> 0 0
> # then sudo mount -a
> # I have worktree setup so the build for each branch will end up in different
> dir:
> # mkdir -p
> /tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
> {code}
> Then in build.properties for each respective branch:
> {code:java}
> ant.gen-doc.skip: true
> build.dir: /tmp/cassandra/trunk/build
> build.dir.lib: /tmp/cassandra/trunk/build/lib
> {code}
> The problem with this is that it fails on rat, because there is not
> "build.dir" property used, it is hardcoded to "build" but there is not
> anything to rat on so it will hang.
--
This message was sent by Atlassian Jira
(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-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679123#comment-17679123
]
Brandon Williams commented on CASSANDRA-17507:
--
bq. That said, the problem occurs only when using v3, and I'd say that the old
v3 protocol is much more likely to be used on a major 3.0/3.x- > 4.0/4.1
upgrade than in a 4.0/4.1 - > 4.0/4.1 upgrade
I agree with you on this. I think we should add a NEWS entry to this effect
and go ahead and commit this. Most likely users will neither read the news
entry nor ever hit the issue this way, and this ticket is evidence that it will
be encountered on upgrade if left in the current state, so I think this is
easily a net positive.
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at
[jira] [Updated] (CASSANDRA-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18027: --- Reviewers: Anthony Grasso, Brandon Williams, derek, Jeremiah Jordan, Jon Haddad, Josh McKenzie (was: Anthony Grasso, Brandon Williams, derek, Jon Haddad, Josh McKenzie) > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (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-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18027: --- Reviewers: Anthony Grasso, Brandon Williams, derek, Jon Haddad, Josh McKenzie (was: Anthony Grasso, Anthony Grasso, Brandon Williams, derek, Jon Haddad, Josh McKenzie) > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (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-18183) rat targets do not adhere to build.dir property
Stefan Miklosovic created CASSANDRA-18183:
-
Summary: rat targets do not adhere to build.dir property
Key: CASSANDRA-18183
URL: https://issues.apache.org/jira/browse/CASSANDRA-18183
Project: Cassandra
Issue Type: Bug
Components: Build
Reporter: Stefan Miklosovic
I detected this when I was trying to put my build dir to ramdisk. I have plenty
of RAM available on my workstation (64GB) and I was thinking about moving
"build" dir to ramdisk so I could make it faster a little bit and also spare
some write cycles to ssd. It can look like irrelevant improvement but I think
that if devs are build the project repeatedly times and times again, this can
easily add up.
{code}
mkdir /tmp/cassandra
# in /etc/fstab
tmpfs /tmp/cassandra tmpfs defaults,noatime,size=2048M,x-gvfs-show,mode=1777 0 0
# then sudo mount -a
# I have worktree setup so the build for each branch will end up in different
dir:
# mkdir -p
/tmp/cassandra/{trunk,cassandra-4.1,cassandra-4.0,cassandra-3.11,cassandra-3.0}
{code}
Then in build.properties for each respective branch:
{code}
ant.gen-doc.skip: true
build.dir: /tmp/cassandra/trunk/build
build.dir.lib: /tmp/cassandra/trunk/build/lib
{code}
The problem with this is that it fails on rat, because there is not "build.dir"
property used, it is hardcoded to "build" but there is not anything to rat on
so it will hang.
--
This message was sent by Atlassian Jira
(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-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18027: --- Reviewers: Anthony Grasso, Anthony Grasso, Brandon Williams, derek, Jon Haddad, Josh McKenzie (was: Anthony Grasso, Brandon Williams, derek, Jeremiah Jordan, Jon Haddad, Josh McKenzie) > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (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-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18027: --- Reviewers: Anthony Grasso, Brandon Williams, derek, Jeremiah Jordan, Jon Haddad, Josh McKenzie (was: Brandon Williams, derek, Jeremiah Jordan) > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
