[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697271#comment-17697271
]
Jacek Lewandowski commented on CASSANDRA-16630:
---
Also JUnit 5 for Cassandra 5 sounds nice :P
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(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-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697269#comment-17697269
]
Jacek Lewandowski commented on CASSANDRA-16630:
---
Is this ticket still in progress? I strongly support the efforts to get JUnit5
in Cassandra tests for many reasons.
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian 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 (a40a7a8a2 -> 4d53fdb57)
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 a40a7a8a2 generate docs for ba88b347 new 4d53fdb57 generate docs for ba88b347 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 (a40a7a8a2) \ N -- N -- N refs/heads/asf-staging (4d53fdb57) 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 4796442 -> 4796442 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-18296) tablehistograms add filter for data table and system table
[ https://issues.apache.org/jira/browse/CASSANDRA-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697207#comment-17697207 ] maxwellguo commented on CASSANDRA-18296: If the options are changed, the way that users use it will change. For example : nodetool tablehistograms ks1 ks2 , for the old usage means show the tablehistograms of table : ks1.ks2; for the new usage means show the tablehistograms of all tables beyond to the two keyspace : ks1 and ks2; So I want to know if I can start this work directly now, don't need to pay attention to other things ,right ？ [~brandon.williams] > tablehistograms add filter for data table and system table > --- > > Key: CASSANDRA-18296 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18296 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > Add some options for nodetool tablehistograms to filter the output > of System tables and data tables. > As we know if we nodetool tablehistograms all tables will be output ,but > system table 's number are too much. > Add options to filter only output data tables or system tables, together with > the already exist ks.tb lists, the output options are just fine. > It seems that tablestats got the -i option that can ignore keyspace, just add > this first, and then to see wether this can meet our needs -- This message was sent by Atlassian Jira (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-17943) Python Upgrade DTests Readme to be revised
[
https://issues.apache.org/jira/browse/CASSANDRA-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697198#comment-17697198
]
Lorina Poland commented on CASSANDRA-17943:
---
>From [~e.dimitrova] :
[https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/README.md]
This is the file, I can add more details etc tomorrow if you need anything and
if you plan on working on it. Not sure how that repo and readme classifies in
the priorities considering how many features you are trying to deal with these
days
!https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/1f...@2x.png!
[README.md|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/README.md]
*Running Upgrade Tests*
{*}Against a local version of Cassandra:{*}These instructions will get upgrade
tests running locally, upgrading to your local source code.
Tests which are not relevant to your local cassandra version (in CASSANDRA_DIR)
will be automatically skipped.
This procedure closely mirrors how CI jobs are configured to run upgrade
tests.• export CASSANDRA_DIR=/your/cassandra/location
• export LOCAL_GIT_REPO=/your/cassandra/location/
• run nosetests:
{quote}nosetests -vs upgrade_tests/{quote}• to preview tests names, use:
{quote}nosetests -v --collect-only upgrade_tests/{quote}Note: Only define the
LOCAL_GIT_REPO env var if you are testing upgrade to a _single_ local version.
For more complicated cases, such as upgrading using multiple local versions,
leave this unset and read the section on the upgrade manifest
below.{*}Customizing the upgrade path{*}In most cases the above instructions
are what you probably need to do. However, in some instances you may need to
further customize the upgrade paths being used, or point to non-local code.
This simple [example pr|https://github.com/riptano/cassandra-dtest/pull/1282]
demonstrates the basic procedure for building custom upgrade paths; these paths
will supercede the normal upgrade tests when run in this fashion.{*}How the
tests work{*}
{*}High level{*}The tests in this submodule are designed to have a single
implementation,
which is then automatically run across a variety of upgrade paths. This means
we can implement a single test and get "free" testing of it on all upgrade
paths
which should be supported. This gives us testing with a pattern of "write once,
run many"
(i.e. write one test and reuse it several times on different
configurations).{*}The
manifest{*}[upgrade_manifest.py|https://app.slack.com/client/T054JNCHW/CUFDK5BHQ/thread/upgrade_manifest.py]
contains metadata and tools concerned with
which upgrade paths to test, and where to find their source. This centralized
location is updated when we need to make changes to which version paths are
upgradeable, and how to find those versions (e.g. via a git tag). This file
also
holds useful metadata about particular versions, such as which binary protocol
versions
they support, and which java versions they can run on.There are two important
concepts in the manifest. The first is known as a
{*}variant{*}. There are two types of variants, 'indev' and 'current'. 'Indev'
stands
for 'in development' which just means a version being worked on, such as an
actively
developed branch which will eventually become a release. 'Current' stands
for 'current release', which just means the most recently released version. For
example,
the manifest might have information about testing an actively developed branch
such as cassandra-3.9. This would have a variant value of 'indev' since it is
referring to a version being actively developed. The most common case is that
testing begins on released versions ('current') and ends on an version being
actively
developed ('indev'). This helps ensure that users picking up released versions
will
be able to upgrade to the code actively being developed should it become the
next
release. If a bug should be discovered then the indev version can be patched
since
it is not yet released code.The second useful concept is that of a {*}version
family{*}. This simply describes which
'version line' a particular version belongs to. For example, Cassandra 3.0.7
belongs
to the {{CASSANDRA_3_0}} version family. Organizing specific versions into
families allows
us to generalize about support, so we can say, for example that: "2.2.x
versions should be
able to upgrade to 3.0.x versions, or 2.2.x versions can skip 3.0.x versions
and upgrade
directly to a 3.x version".{*}Code generation{*}As described above, the upgrade
testing tools allow a "write once, run many"
pattern, which is to say one test can be written and then reused over a number
of different upgrade paths and configurations. This is made possible through
code generation.For example, a hypothetical test called
'test_authentication_during_upgrade',
would be
[jira] [Comment Edited] (CASSANDRA-17943) Python Upgrade DTests Readme to be revised
[
https://issues.apache.org/jira/browse/CASSANDRA-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697198#comment-17697198
]
Lorina Poland edited comment on CASSANDRA-17943 at 3/7/23 1:16 AM:
---
>From [~e.dimitrova] :
[https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/README.md]
This is the file:
[README.md|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/README.md]
*Running Upgrade Tests*
{*}Against a local version of Cassandra:{*}These instructions will get upgrade
tests running locally, upgrading to your local source code.
Tests which are not relevant to your local cassandra version (in CASSANDRA_DIR)
will be automatically skipped.
This procedure closely mirrors how CI jobs are configured to run upgrade
tests.• export CASSANDRA_DIR=/your/cassandra/location
• export LOCAL_GIT_REPO=/your/cassandra/location/
• run nosetests:
{quote}nosetests -vs upgrade_tests/
{quote}
• to preview tests names, use:
{quote}nosetests -v --collect-only upgrade_tests/
{quote}
Note: Only define the LOCAL_GIT_REPO env var if you are testing upgrade to a
_single_ local version. For more complicated cases, such as upgrading using
multiple local versions, leave this unset and read the section on the upgrade
manifest below.{*}Customizing the upgrade path{*}In most cases the above
instructions are what you probably need to do. However, in some instances you
may need to further customize the upgrade paths being used, or point to
non-local code. This simple [example
pr|https://github.com/riptano/cassandra-dtest/pull/1282] demonstrates the basic
procedure for building custom upgrade paths; these paths will supercede the
normal upgrade tests when run in this fashion.{*}How the tests work{*}
{*}High level{*}The tests in this submodule are designed to have a single
implementation,
which is then automatically run across a variety of upgrade paths. This means
we can implement a single test and get "free" testing of it on all upgrade
paths
which should be supported. This gives us testing with a pattern of "write once,
run many"
(i.e. write one test and reuse it several times on different
configurations).{*}The
manifest{*}[upgrade_manifest.py|https://app.slack.com/client/T054JNCHW/CUFDK5BHQ/thread/upgrade_manifest.py]
contains metadata and tools concerned with
which upgrade paths to test, and where to find their source. This centralized
location is updated when we need to make changes to which version paths are
upgradeable, and how to find those versions (e.g. via a git tag). This file
also
holds useful metadata about particular versions, such as which binary protocol
versions
they support, and which java versions they can run on.There are two important
concepts in the manifest. The first is known as a
{*}variant{*}. There are two types of variants, 'indev' and 'current'. 'Indev'
stands
for 'in development' which just means a version being worked on, such as an
actively
developed branch which will eventually become a release. 'Current' stands
for 'current release', which just means the most recently released version. For
example,
the manifest might have information about testing an actively developed branch
such as cassandra-3.9. This would have a variant value of 'indev' since it is
referring to a version being actively developed. The most common case is that
testing begins on released versions ('current') and ends on an version being
actively
developed ('indev'). This helps ensure that users picking up released versions
will
be able to upgrade to the code actively being developed should it become the
next
release. If a bug should be discovered then the indev version can be patched
since
it is not yet released code.The second useful concept is that of a {*}version
family{*}. This simply describes which
'version line' a particular version belongs to. For example, Cassandra 3.0.7
belongs
to the {{CASSANDRA_3_0}} version family. Organizing specific versions into
families allows
us to generalize about support, so we can say, for example that: "2.2.x
versions should be
able to upgrade to 3.0.x versions, or 2.2.x versions can skip 3.0.x versions
and upgrade
directly to a 3.x version".{*}Code generation{*}As described above, the upgrade
testing tools allow a "write once, run many"
pattern, which is to say one test can be written and then reused over a number
of different upgrade paths and configurations. This is made possible through
code generation.For example, a hypothetical test called
'test_authentication_during_upgrade',
would be implemented as a method in an existing class. At runtime we
effectively treat that class as a template, and generate subclasses of it to
cover
upgrade paths and configurations of interest. So that singular test once
written
can effectively create many tests.T
[jira] [Commented] (CASSANDRA-17512) DOC - Fix Dynamo paper links to have working urls
[ https://issues.apache.org/jira/browse/CASSANDRA-17512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697197#comment-17697197 ] Lorina Poland commented on CASSANDRA-17512: --- [~erickramirezau] Status? It looks like the PR was closed without merging. > DOC - Fix Dynamo paper links to have working urls > - > > Key: CASSANDRA-17512 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17512 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Prashant Bhuruk >Assignee: Prashant Bhuruk >Priority: Normal > > References to Dynamo paper at the Architecture > [Overview|https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html] > and > [Dynamo|https://cassandra.apache.org/doc/latest/cassandra/architecture/dynamo.html] > pages refer to an URL that gives 404 error. > We need to update the URL to point to another copy of the same paper. > Before: > [http://courses.cse.tamu.edu/caverlee/csce438/readings/dynamo-paper.pdf] > After: [https://www.cs.cornell.edu/courses/cs5414/2017fa/papers/dynamo.pdf] -- This message was sent by Atlassian Jira (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-18082) Broken link in the documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-18082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18082: -- Labels: low-hanging-fruit (was: ) > Broken link in the documentation > > > Key: CASSANDRA-18082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18082 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Tibor Repasi >Priority: Normal > Labels: low-hanging-fruit > > At the page Cassandra > [Operating|https://cassandra.apache.org/doc/latest/cassandra/operating/index.html], > the link to Snitches on the left menu-pane is broken for at least latest and > 4.0 versions. As [~brandonwilliams] pointed out, the page which should be > linked still exists at > [https://cassandra.apache.org/doc/latest/cassandra/architecture/snitch.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17844) DOC - Fix typo in CQL types page
[
https://issues.apache.org/jira/browse/CASSANDRA-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland updated CASSANDRA-17844:
--
Labels: low-hanging-fruit (was: )
> DOC - Fix typo in CQL types page
>
>
> Key: CASSANDRA-17844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17844
> Project: Cassandra
> Issue Type: Task
> Components: Documentation
>Reporter: Yaniv Kaul
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Typo @ https://cassandra.apache.org/doc/trunk/cassandra/cql/types.html:
> bq. the {color:#DE350B}while{color} collection has to be read
> should be:
> bq. the {color:#00875A}whole{color} collection has to be read
--
This message was sent by Atlassian Jira
(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-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18228: -- Change Category: Code Clarity Complexity: Normal Status: Open (was: Triage Needed) > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- This message was sent by Atlassian Jira (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-18284) Create 2023 Google Season of Documentation proposal and related blog post
[ https://issues.apache.org/jira/browse/CASSANDRA-18284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland updated CASSANDRA-18284: -- Change Category: Performance Complexity: Normal Status: Open (was: Triage Needed) > Create 2023 Google Season of Documentation proposal and related blog post > - > > Key: CASSANDRA-18284 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18284 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > > Create a Google Season of Documentation proposal and related blog post. > * Apply for Open Collective account. > * Apply for GSoD grant. Requires writing blog post for URL for application. > * FYI - ticket will be close once GSoD application is submitted. > ** If grant is successful, modify blog post to advertise for tech writer > applicants. > ** Select tech writers. -- This message was sent by Atlassian Jira (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-18228) Reorganize Apache C* docs in trunk branch to match the IA
[ https://issues.apache.org/jira/browse/CASSANDRA-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697189#comment-17697189 ] Lorina Poland commented on CASSANDRA-18228: --- [https://github.com/apache/cassandra/pull/2198] opened for consideration on this ticket. > Reorganize Apache C* docs in trunk branch to match the IA > - > > Key: CASSANDRA-18228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18228 > Project: Cassandra > Issue Type: New Feature > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Fix For: 4.x > > > An agreed-upon Information Architecture will be used to reorganize the C* 5.0 > docs. > IA doc: > https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing -- This message was sent by Atlassian Jira (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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18304:
-
Fix Version/s: 4.x
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18304:
Test and Documentation Plan: changes
Status: Patch Available (was: Open)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697176#comment-17697176
]
Paulo Motta commented on CASSANDRA-18304:
-
Added dtest to reproduce issue.
Fix is to filter endpoints on with {{StorageProxy::shouldHint}} on
{{{}StorageProxy.submitHint{}}}, not sure if this has any unintended
consequences.
Can you take a look [~benedict] [~aleksey] ?
* [4.1 PR|https://github.com/apache/cassandra/pull/2196]
* [trunk PR|https://github.com/apache/cassandra/pull/2197]
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2327/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2327/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2328/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2328/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18304:
-
Fix Version/s: 4.1.x
(was: 4.1.1)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18304:
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.1.1
Severity: Normal
Status: Open (was: Triage Needed)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.1
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(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-18304) hinted_handoff_enabled=false is not honored
Paulo Motta created CASSANDRA-18304:
---
Summary: hinted_handoff_enabled=false is not honored
Key: CASSANDRA-18304
URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
Project: Cassandra
Issue Type: Bug
Components: Consistency/Hints
Reporter: Paulo Motta
Assignee: Paulo Motta
I've had some dtests with disabled hints failing.
After investigation it seems that CASSANDRA-17164 moved hint submission on
timeout from
[RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
to
[AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
{{StorageProxy.shouldHint}} which ultimately checks if
{{{}hinted_handoff_enabled=true{}}}.
This could cause some tests which expect hints to be disabled to fail
intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: ninja-fix contribulyze.py to use python (not python3)
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-builds.git The following commit(s) were added to refs/heads/trunk by this push: new 138d725 ninja-fix contribulyze.py to use python (not python3) 138d725 is described below commit 138d725d5dbd54041f31d14a0dcd81434b32c799 Author: Mick Semb Wever AuthorDate: Mon Mar 6 23:07:00 2023 +0100 ninja-fix contribulyze.py to use python (not python3) --- contribulyze/contribulyze.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contribulyze/contribulyze.py b/contribulyze/contribulyze.py index bbff8c5..f7489b3 100755 --- a/contribulyze/contribulyze.py +++ b/contribulyze/contribulyze.py @@ -1,4 +1,4 @@ -#!/usr/bin/env python3 +#!/usr/bin/env python # -*- coding: utf-8 -*- # # - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18144:
--
Resolution: Fixed
Status: Resolved (was: Open)
Spurious dtest failure misled to this ticket
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-17973) Change trunk 4.2 to 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697141#comment-17697141
]
Brandon Williams commented on CASSANDRA-17973:
--
I reran the jvm dtests that timed out
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/881/workflows/a293e9ea-84ed-4aeb-bc29-fa3c635f9efe/jobs/12690]
just to be certain, and they passed. Everything looks good to me, +1.
bq. remove older serialization binary files we're no longer use in tests…
Can confirm that the 0.7 files are no longer needed :) Also thank you for the
checkpoint commits, that made reviewing smoother.
> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> 1. Bump trunk's version
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
> -
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
> -
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
> - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
> -
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
--
This message was sent by Atlassian Jira
(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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-18144:
-
Source Control Link:
https://github.com/apache/cassandra/commit/0a0e06847bf10aa88a3a30c239c507a64f949d74
(was:
https://github.com/apache/cassandra/commit/d45172bcdb9c5d7c9f33c1e18aeb29059a4babec)
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697140#comment-17697140
]
Jon Meredith commented on CASSANDRA-18144:
--
I just double-checked the commit
[https://github.com/apache/cassandra/commit/0a0e06847bf10aa88a3a30c239c507a64f949d74]
and it only modifies the java test, so don't see how it could affect the
Python dtest.
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697138#comment-17697138
]
Michael Semb Wever edited comment on CASSANDRA-18144 at 3/6/23 8:44 PM:
The failure is found
[here|https://ci-cassandra.apache.org/job/Cassandra-trunk/1473/testReport/dtest.replace_address_test/TestReplaceAddress/test_fail_without_replace/].
It is a `{{TimeoutError}}` which we don't (re-)open tickets for, as described
[here|https://cwiki.apache.org/confluence/display/CASSANDRA/Build+Lead]
{quote}
For failures with "Timeout …", we can ignore them , as it's considered
test-infrastructure failures. …
{quote}
Open to suggestions on how to improve this, especially for new Build Leads
figuring this out…
was (Author: michaelsembwever):
The failure is found
[here|https://ci-cassandra.apache.org/job/Cassandra-trunk/1473/testReport/dtest.replace_address_test/TestReplaceAddress/test_fail_without_replace/].
It is a `{{TimeoutError}}` which we don't (re-)open tickets for, as described
[here|]
{quote}
For failures with "Timeout …", we can ignore them , as it's considered
test-infrastructure failures. …
{quote}
Open to suggestions on how to improve this, especially for new Build Leads
figuring this out…
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697138#comment-17697138
]
Michael Semb Wever commented on CASSANDRA-18144:
The failure is found
[here|https://ci-cassandra.apache.org/job/Cassandra-trunk/1473/testReport/dtest.replace_address_test/TestReplaceAddress/test_fail_without_replace/].
It is a `{{TimeoutError}}` which we don't (re-)open tickets for, as described
[here|]
{quote}
For failures with "Timeout …", we can ignore them , as it's considered
test-infrastructure failures. …
{quote}
Open to suggestions on how to improve this, especially for new Build Leads
figuring this out…
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-18303) Feature documentation lost / moved out of focus
[ https://issues.apache.org/jira/browse/CASSANDRA-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697133#comment-17697133 ] Tibor Repasi commented on CASSANDRA-18303: -- It's the same patch as with CASSANDRA-17344, but applied to another file. > Feature documentation lost / moved out of focus > --- > > Key: CASSANDRA-18303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Fix For: 4.1.x, 4.x > > > Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 > and now the documentation on the website page "Cassandra/Operating/Virtual > tables" shows an outdated version for > [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] > and > [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18071) Allow to use user-defined functions (UDF) as masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697131#comment-17697131 ] Andres de la Peña commented on CASSANDRA-18071: --- Rebased on top of CASSANDRA-18068, CASSANDRA-18069 and CASSANDRA-18070: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/2156]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2697/workflows/bce3e33c-dce7-4365-9664-ff0e7569531e] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2697/workflows/af9bef23-2d3e-4228-91ea-405d113b653f]| > Allow to use user-defined functions (UDF) as masking functions > -- > > Key: CASSANDRA-18071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18071 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 40m > Remaining Estimate: 0h > > Allow to attach user-defined functions (UDF) to tables so they can be used as > masking functions, as defined by > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > This will be similar to the native data masking functions introduced by > CASSANDRA-17941 and attached to tables by CASSANDRA-18068. -- This message was sent by Atlassian Jira (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-18070) Add a new SELECT_MASKED permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697130#comment-17697130
]
Andres de la Peña commented on CASSANDRA-18070:
---
Rebased on top of CASSANDRA-18068 and CASSANDRA-18069:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2146]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2695/workflows/b7c2534d-2e9d-408f-af20-5307350f19c4]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2695/workflows/b059cf94-94da-4bd9-adb9-bc0d91b6a1f2]|
|[dtest|https://github.com/apache/cassandra-dtest/pull/209]|
> Add a new SELECT_MASKED permission
> --
>
> Key: CASSANDRA-18070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18070
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add a table-level SELECT_MASKED permission allowing certain users to query
> but not see the unmasked columns introduced by CASSANDRA-18068, assuming that
> they also have the SELECT permission on the table, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> It would look like:
> {code}
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON ALL TABLE patients TO unprivileged_user;
> > GRANT SELECT ON ALL TABLE patients TO privileged_user;
> > GRANT SELECT_MASKED ON ALL TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User has
> no UNMASK nor SELECT_UNMASK permission on "
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18212) Reduce memory allocations of calls to ByteBufer.duplicate() made in org.apache.cassandra.transport.CBUtil#writeValue
[ https://issues.apache.org/jira/browse/CASSANDRA-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18212: -- Fix Version/s: 4.2 Source Control Link: https://github.com/apache/cassandra/commit/35f8da66f9b05d18b4177f8d2e1b86c772ad2221 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Reduce memory allocations of calls to ByteBufer.duplicate() made in > org.apache.cassandra.transport.CBUtil#writeValue > > > Key: CASSANDRA-18212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18212 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Natnael Adere >Assignee: Natnael Adere >Priority: Normal > Fix For: 4.2 > > Attachments: DiskBased.png, allocations-after.html, > allocations-before.html > > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently, > org.apache.cassandra.transport.CBUtil#writeValue(java.nio.ByteBuffer, > io.netty.buffer.ByteBuf) calls ByteBufer.duplicate() and is found to be 20% > of memory allocations in production. No changes have been made to reduce this > but there is discussion related to the issue in CASSANDRA-13741. Attached > below are the performance result for disk based queries and mostly memory > based queries. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Reduce memory allocations of calls to ByteBufer.duplicate() made in org.apache.cassandra.transport.CBUtil#writeValue
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 35f8da66f9 Reduce memory allocations of calls to ByteBufer.duplicate()
made in org.apache.cassandra.transport.CBUtil#writeValue
35f8da66f9 is described below
commit 35f8da66f9b05d18b4177f8d2e1b86c772ad2221
Author: Natnael Adere
AuthorDate: Thu Mar 2 11:50:07 2023 -0800
Reduce memory allocations of calls to ByteBufer.duplicate() made in
org.apache.cassandra.transport.CBUtil#writeValue
patch by Natnael Adere; reviewed by Benedict Elliott Smith, David Capwell
for CASSANDRA-18212
---
CHANGES.txt| 1 +
.../org/apache/cassandra/transport/CBUtil.java | 45 -
.../apache/cassandra/transport/WriteBytesTest.java | 58 ++
.../org/apache/cassandra/utils/Generators.java | 34 -
4 files changed, 134 insertions(+), 4 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 72bca4b3c7..4563765ebc 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Reduce memory allocations of calls to ByteBufer.duplicate() made in
org.apache.cassandra.transport.CBUtil#writeValue (CASSANDRA-18212)
* CEP-17: SSTable API (CASSANDRA-17056)
* Gossip stateMapOrdering does not have correct ordering when both
EndpointState are in the bootstrapping set (CASSANDRA-18292)
* Snapshot only sstables containing mismatching ranges on preview repair
mismatch (CASSANDRA-17561)
diff --git a/src/java/org/apache/cassandra/transport/CBUtil.java
b/src/java/org/apache/cassandra/transport/CBUtil.java
index 6cab63855e..bdb1a909ad 100644
--- a/src/java/org/apache/cassandra/transport/CBUtil.java
+++ b/src/java/org/apache/cassandra/transport/CBUtil.java
@@ -32,7 +32,6 @@ import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.UUID;
-
import io.netty.buffer.ByteBuf;
import io.netty.buffer.ByteBufAllocator;
import io.netty.buffer.ByteBufUtil;
@@ -46,6 +45,7 @@ import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.Pair;
import org.apache.cassandra.utils.TimeUUID;
import org.apache.cassandra.utils.UUIDGen;
+import org.apache.cassandra.utils.memory.MemoryUtil;
/**
* ByteBuf utility methods.
@@ -69,6 +69,15 @@ public abstract class CBUtil
}
};
+private final static FastThreadLocal localDirectBuffer = new
FastThreadLocal()
+{
+@Override
+protected ByteBuffer initialValue()
+{
+return MemoryUtil.getHollowDirectByteBuffer();
+}
+};
+
private final static FastThreadLocal TL_CHAR_BUFFER = new
FastThreadLocal<>();
private CBUtil() {}
@@ -478,7 +487,35 @@ public abstract class CBUtil
cb.writeInt(remaining);
if (remaining > 0)
-cb.writeBytes(bytes.duplicate());
+addBytes(bytes, cb);
+}
+
+public static void addBytes(ByteBuffer src, ByteBuf dest)
+{
+if (src.remaining() == 0)
+return;
+
+int length = src.remaining();
+
+if (src.hasArray())
+{
+// Heap buffers are copied using a raw array instead of shared
heap buffer and MemoryUtil.unsafe to avoid a CMS bug, which causes the JVM to
crash with the follwing:
+// # Problematic frame:
+// # V [libjvm.dylib+0x63e858] void
ParScanClosure::do_oop_work(unsigned int*, bool, bool)+0x94
+// More details can be found here:
https://bugs.openjdk.org/browse/JDK-8222798
+byte[] array = src.array();
+dest.writeBytes(array, src.arrayOffset() + src.position(), length);
+}
+else if (src.isDirect())
+{
+ByteBuffer local = getLocalDirectBuffer();
+MemoryUtil.duplicateDirectByteBuffer(src, local);
+dest.writeBytes(local);
+}
+else
+{
+dest.writeBytes(src.duplicate());
+}
}
public static int sizeOfValue(byte[] bytes)
@@ -614,4 +651,8 @@ public abstract class CBUtil
return bytes;
}
+private static ByteBuffer getLocalDirectBuffer()
+{
+return localDirectBuffer.get();
+}
}
diff --git a/test/unit/org/apache/cassandra/transport/WriteBytesTest.java
b/test/unit/org/apache/cassandra/transport/WriteBytesTest.java
new file mode 100644
index 00..1dd1c796e8
--- /dev/null
+++ b/test/unit/org/apache/cassandra/transport/WriteBytesTest.java
@@ -0,0 +1,58 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not us
[jira] [Commented] (CASSANDRA-18212) Reduce memory allocations of calls to ByteBufer.duplicate() made in org.apache.cassandra.transport.CBUtil#writeValue
[ https://issues.apache.org/jira/browse/CASSANDRA-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697125#comment-17697125 ] David Capwell commented on CASSANDRA-18212: --- thanks, ill merge today > Reduce memory allocations of calls to ByteBufer.duplicate() made in > org.apache.cassandra.transport.CBUtil#writeValue > > > Key: CASSANDRA-18212 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18212 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Natnael Adere >Assignee: Natnael Adere >Priority: Normal > Attachments: DiskBased.png, allocations-after.html, > allocations-before.html > > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently, > org.apache.cassandra.transport.CBUtil#writeValue(java.nio.ByteBuffer, > io.netty.buffer.ByteBuf) calls ByteBufer.duplicate() and is found to be 20% > of memory allocations in production. No changes have been made to reduce this > but there is discussion related to the issue in CASSANDRA-13741. Attached > below are the performance result for disk based queries and mostly memory > based queries. -- This message was sent by Atlassian Jira (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-18069) Add a new UNMASK permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697114#comment-17697114
]
Andres de la Peña commented on CASSANDRA-18069:
---
Just a final detail, I'm making the new {{UNMASK}} keyword unreserved.
Whereas other permissions have all been added as reserved keywords, I don't
think there is a need to do so. By not making it reserved we can save a
headache to users having keyspaces, tables or columns named "unmask".
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2125]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2693/workflows/c9c9b194-681b-465d-8926-3735bc757973]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2693/workflows/8ccfa2dc-b37a-4588-86a4-83f0dd5e9e1b]|
|[dtest|https://github.com/apache/cassandra-dtest/pull/208]|
> Add a new UNMASK permission
> ---
>
> Key: CASSANDRA-18069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18069
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Add a new UNMASK permission allowing users with that permission to see the
> data masked by the masking functions attached to columns introduced by
> CASSANDRA-18068, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> It would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH default(),
> birth date MASKED WITH default()
> );
>
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21');
>
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON TABLE patients TO unprivileged_user;
> > GRANT SELECT ON TABLE patients TO privileged_user;
> > GRANT UNMASK ON TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
>
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name| birth
> -+
> ale | 1900-01-01
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name | birth
> ---+
> alice | 1982-12-21
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18300) Support robust downgradability
[ https://issues.apache.org/jira/browse/CASSANDRA-18300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18300: -- Summary: Support robust downgradability (was: The user should be able to try the new version with the ability to go back) > Support robust downgradability > -- > > Key: CASSANDRA-18300 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18300 > Project: Cassandra > Issue Type: Epic >Reporter: Jacek Lewandowski >Priority: Normal > > List of all the issues, improvements, assumptions and other things we should > consider to allow the user to go back to the previous version without > problems. -- This message was sent by Atlassian Jira (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-17973) Change trunk 4.2 to 5.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17973:
-
Reviewers: Brandon Williams
Status: Review In Progress (was: Patch Available)
> Change trunk 4.2 to 5.0
> ---
>
> Key: CASSANDRA-17973
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17973
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> 1. Bump trunk's version
> {code}
> git switch trunk
> # increment version to 5.0
> edit build.xml debian/changelog CHANGES.txt NEWS.txt README.asc
> {code}
> 2. Update jvm-dtest supported upgrade paths
> -
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTestBase.java#L85-L96
>
> 3. Update `4.2` to jira versions
> Change `4.2` to `5.0`
> Change `4.x` to `5.x`
> 4. Update docker images to include cassandra-5.0
> (Docker images also need to be deployed)
> 5. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> 6. Add dtest version and upgrade paths
> -
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
> - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
> -
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L41
> 7. Update how_to_commit documentation
> https://github.com/apache/cassandra-website/blob/trunk/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc
--
This message was sent by Atlassian Jira
(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-18268) Log completed status with cleanup and garbagecollect operations
[ https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697080#comment-17697080 ] Kan Maung commented on CASSANDRA-18268: --- +1 > Log completed status with cleanup and garbagecollect operations > --- > > Key: CASSANDRA-18268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18268 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Kan Maung >Assignee: Milan Krisko >Priority: Normal > > Whenever a cleanup or garbagecollect operation is issued from nodetool, there > is no log statuses for the start and end of the operation at the node level > although statuses on individual sstables are captured. Start can be inferred, > but it is difficult to know when the operation has completed because there is > no log message. > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable1 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable1 successfully > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:364 - No > sstables to GARBAGE_COLLECT for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable2 successfully > > This improvement proposes adding additional for start and end statuses log > messages for the above operation at the node level. I.e., > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Starting GARBAGE_COLLECT > …. > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Completed GARBAGE_COLLECT -- This message was sent by Atlassian Jira (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-18268) Log completed status with cleanup and garbagecollect operations
[ https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697049#comment-17697049 ] Brad Schoening commented on CASSANDRA-18268: +1 > Log completed status with cleanup and garbagecollect operations > --- > > Key: CASSANDRA-18268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18268 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Kan Maung >Assignee: Milan Krisko >Priority: Normal > > Whenever a cleanup or garbagecollect operation is issued from nodetool, there > is no log statuses for the start and end of the operation at the node level > although statuses on individual sstables are captured. Start can be inferred, > but it is difficult to know when the operation has completed because there is > no log message. > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable1 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable1 successfully > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:364 - No > sstables to GARBAGE_COLLECT for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable2 successfully > > This improvement proposes adding additional for start and end statuses log > messages for the above operation at the node level. I.e., > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Starting GARBAGE_COLLECT > …. > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Completed GARBAGE_COLLECT -- This message was sent by Atlassian Jira (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-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697048#comment-17697048 ] Brad Schoening commented on CASSANDRA-18283: LGTM, +1 > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: image-2023-02-28-08-08-24-727.png > > Time Spent: 20m > Remaining Estimate: 0h > > The nodetool tablestats command lacks some available details which would be > very useful to report upon. This is especially helpful in > database-as-a-service environments where servers and their disk files are not > directly observable by users. > 1. Currently, for LCS tablestats reports useful details about the number of > sstables in each level: > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > This type of additional detail about the sstables is absent from STCS and > TWCS as it only reports the table count. > 1a) For STCS, tablestats should report the max sstable file size on disk. > This is useful to know if compaction has failed due to disk space or if a > forced compaction created a jumbo table. > 1b) For TWCS, tablestats should report the min & max timestamp, and duration > of the sstables representing windows. This is useful to know if > out-of-window writes or rows w/out a TTL have lead many more sstables on disk > than expected by the time window configuration. > STCs example: > SSTable count: 6635 > SSTable STCS max size: 122,000,000,000 > STCs example: > SSTable count: 6635 > SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s > 2. While tablestats reports both memtable and disk file sstable statistics. > It is useful these are in the same command, but it would clarify the output > to separate mem vs disk into two sections > i.e., > -- File statistics > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > -- Memtable statistics > Bloom filter false positives: 12184123 > Bloom filter false ratio: 0.07203 > Bloom filter space used: 16874424 > Bloom filter off heap memory used: 16821344 > Index summary off heap memory used: 7525546 > Space used (live): 1324067896238 > 3. Read / Write count should also be reported as a ratio, such as: > Local read count: 202961459 > Local write count: 40554481 > Local read/write ratio: 5:1 > Local read latency: 1.957 ms > Local write count: 40554481 > Local write latency: 0.040 ms -- This message was sent by Atlassian Jira (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-18268) Log completed status with cleanup and garbagecollect operations
[ https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697047#comment-17697047 ] Brandon Williams commented on CASSANDRA-18268: -- +1 > Log completed status with cleanup and garbagecollect operations > --- > > Key: CASSANDRA-18268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18268 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Kan Maung >Assignee: Milan Krisko >Priority: Normal > > Whenever a cleanup or garbagecollect operation is issued from nodetool, there > is no log statuses for the start and end of the operation at the node level > although statuses on individual sstables are captured. Start can be inferred, > but it is difficult to know when the operation has completed because there is > no log message. > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable1 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable1 successfully > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:364 - No > sstables to GARBAGE_COLLECT for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable2 successfully > > This improvement proposes adding additional for start and end statuses log > messages for the above operation at the node level. I.e., > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Starting GARBAGE_COLLECT > …. > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Completed GARBAGE_COLLECT -- This message was sent by Atlassian Jira (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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697045#comment-17697045
]
Ekaterina Dimitrova commented on CASSANDRA-18144:
-
Hey [~dchenbecker] , I believe we can close this one as it fixed a unit test
and it cannot affect a Python DTest. I think the python DTest is probably a
flaky one. I can see it actually failed twice in the past 30 runs.
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18144:
--
Resolution: (was: Fixed)
Status: Open (was: Resolved)
This appears to have broken one of the dtests:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1473/testReport/dtest.replace_address_test/TestReplaceAddress/
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(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-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697022#comment-17697022 ] Brandon Williams edited comment on CASSANDRA-18283 at 3/6/23 4:31 PM: -- LGTM, +1. This is probably worthy of a small note in NEWS.txt since it adds new metrics. was (Author: brandon.williams): LGTM, +1. This probably worthy of a small note in NEWS.txt since it adds new metrics. > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: image-2023-02-28-08-08-24-727.png > > Time Spent: 20m > Remaining Estimate: 0h > > The nodetool tablestats command lacks some available details which would be > very useful to report upon. This is especially helpful in > database-as-a-service environments where servers and their disk files are not > directly observable by users. > 1. Currently, for LCS tablestats reports useful details about the number of > sstables in each level: > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > This type of additional detail about the sstables is absent from STCS and > TWCS as it only reports the table count. > 1a) For STCS, tablestats should report the max sstable file size on disk. > This is useful to know if compaction has failed due to disk space or if a > forced compaction created a jumbo table. > 1b) For TWCS, tablestats should report the min & max timestamp, and duration > of the sstables representing windows. This is useful to know if > out-of-window writes or rows w/out a TTL have lead many more sstables on disk > than expected by the time window configuration. > STCs example: > SSTable count: 6635 > SSTable STCS max size: 122,000,000,000 > STCs example: > SSTable count: 6635 > SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s > 2. While tablestats reports both memtable and disk file sstable statistics. > It is useful these are in the same command, but it would clarify the output > to separate mem vs disk into two sections > i.e., > -- File statistics > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > -- Memtable statistics > Bloom filter false positives: 12184123 > Bloom filter false ratio: 0.07203 > Bloom filter space used: 16874424 > Bloom filter off heap memory used: 16821344 > Index summary off heap memory used: 7525546 > Space used (live): 1324067896238 > 3. Read / Write count should also be reported as a ratio, such as: > Local read count: 202961459 > Local write count: 40554481 > Local read/write ratio: 5:1 > Local read latency: 1.957 ms > Local write count: 40554481 > Local write latency: 0.040 ms -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697024#comment-17697024 ] Michael Semb Wever commented on CASSANDRA-18106: bq. To put another on the table, I think we could make a matrix for each java version and then run the dtests by java matrix … Yes! ( that's what I was trying to describe :D ) > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18283: - Status: Ready to Commit (was: Review In Progress) > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: image-2023-02-28-08-08-24-727.png > > Time Spent: 20m > Remaining Estimate: 0h > > The nodetool tablestats command lacks some available details which would be > very useful to report upon. This is especially helpful in > database-as-a-service environments where servers and their disk files are not > directly observable by users. > 1. Currently, for LCS tablestats reports useful details about the number of > sstables in each level: > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > This type of additional detail about the sstables is absent from STCS and > TWCS as it only reports the table count. > 1a) For STCS, tablestats should report the max sstable file size on disk. > This is useful to know if compaction has failed due to disk space or if a > forced compaction created a jumbo table. > 1b) For TWCS, tablestats should report the min & max timestamp, and duration > of the sstables representing windows. This is useful to know if > out-of-window writes or rows w/out a TTL have lead many more sstables on disk > than expected by the time window configuration. > STCs example: > SSTable count: 6635 > SSTable STCS max size: 122,000,000,000 > STCs example: > SSTable count: 6635 > SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s > 2. While tablestats reports both memtable and disk file sstable statistics. > It is useful these are in the same command, but it would clarify the output > to separate mem vs disk into two sections > i.e., > -- File statistics > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > -- Memtable statistics > Bloom filter false positives: 12184123 > Bloom filter false ratio: 0.07203 > Bloom filter space used: 16874424 > Bloom filter off heap memory used: 16821344 > Index summary off heap memory used: 7525546 > Space used (live): 1324067896238 > 3. Read / Write count should also be reported as a ratio, such as: > Local read count: 202961459 > Local write count: 40554481 > Local read/write ratio: 5:1 > Local read latency: 1.957 ms > Local write count: 40554481 > Local write latency: 0.040 ms -- This message was sent by Atlassian Jira (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-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18283: - Status: Review In Progress (was: Patch Available) > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: image-2023-02-28-08-08-24-727.png > > Time Spent: 20m > Remaining Estimate: 0h > > The nodetool tablestats command lacks some available details which would be > very useful to report upon. This is especially helpful in > database-as-a-service environments where servers and their disk files are not > directly observable by users. > 1. Currently, for LCS tablestats reports useful details about the number of > sstables in each level: > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > This type of additional detail about the sstables is absent from STCS and > TWCS as it only reports the table count. > 1a) For STCS, tablestats should report the max sstable file size on disk. > This is useful to know if compaction has failed due to disk space or if a > forced compaction created a jumbo table. > 1b) For TWCS, tablestats should report the min & max timestamp, and duration > of the sstables representing windows. This is useful to know if > out-of-window writes or rows w/out a TTL have lead many more sstables on disk > than expected by the time window configuration. > STCs example: > SSTable count: 6635 > SSTable STCS max size: 122,000,000,000 > STCs example: > SSTable count: 6635 > SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s > 2. While tablestats reports both memtable and disk file sstable statistics. > It is useful these are in the same command, but it would clarify the output > to separate mem vs disk into two sections > i.e., > -- File statistics > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > -- Memtable statistics > Bloom filter false positives: 12184123 > Bloom filter false ratio: 0.07203 > Bloom filter space used: 16874424 > Bloom filter off heap memory used: 16821344 > Index summary off heap memory used: 7525546 > Space used (live): 1324067896238 > 3. Read / Write count should also be reported as a ratio, such as: > Local read count: 202961459 > Local write count: 40554481 > Local read/write ratio: 5:1 > Local read latency: 1.957 ms > Local write count: 40554481 > Local write latency: 0.040 ms -- This message was sent by Atlassian Jira (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-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697022#comment-17697022 ] Brandon Williams commented on CASSANDRA-18283: -- LGTM, +1. This probably worthy of a small note in NEWS.txt since it adds new metrics. > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: image-2023-02-28-08-08-24-727.png > > Time Spent: 20m > Remaining Estimate: 0h > > The nodetool tablestats command lacks some available details which would be > very useful to report upon. This is especially helpful in > database-as-a-service environments where servers and their disk files are not > directly observable by users. > 1. Currently, for LCS tablestats reports useful details about the number of > sstables in each level: > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > This type of additional detail about the sstables is absent from STCS and > TWCS as it only reports the table count. > 1a) For STCS, tablestats should report the max sstable file size on disk. > This is useful to know if compaction has failed due to disk space or if a > forced compaction created a jumbo table. > 1b) For TWCS, tablestats should report the min & max timestamp, and duration > of the sstables representing windows. This is useful to know if > out-of-window writes or rows w/out a TTL have lead many more sstables on disk > than expected by the time window configuration. > STCs example: > SSTable count: 6635 > SSTable STCS max size: 122,000,000,000 > STCs example: > SSTable count: 6635 > SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s > 2. While tablestats reports both memtable and disk file sstable statistics. > It is useful these are in the same command, but it would clarify the output > to separate mem vs disk into two sections > i.e., > -- File statistics > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > -- Memtable statistics > Bloom filter false positives: 12184123 > Bloom filter false ratio: 0.07203 > Bloom filter space used: 16874424 > Bloom filter off heap memory used: 16821344 > Index summary off heap memory used: 7525546 > Space used (live): 1324067896238 > 3. Read / Write count should also be reported as a ratio, such as: > Local read count: 202961459 > Local write count: 40554481 > Local read/write ratio: 5:1 > Local read latency: 1.957 ms > Local write count: 40554481 > Local write latency: 0.040 ms -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697021#comment-17697021 ] Brandon Williams commented on CASSANDRA-18106: -- I see. To put another on the table, I think we could make a matrix for each java version and then run the dtests by java matrix, that way you are declaring 'run all the upgrade tests that work with this java version.' I don't think of any this will need CCM support to accomplish these goals though. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18069) Add a new UNMASK permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697019#comment-17697019
]
Andres de la Peña edited comment on CASSANDRA-18069 at 3/6/23 4:13 PM:
---
Just rebased on top of CASSANDRA-18068:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2125]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2691/workflows/5c61f955-7c72-421a-ae2b-b4e40b498b55]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2691/workflows/e2f3-97f7-4d2c-8c32-48eab4f37166]|
|[dtest|https://github.com/apache/cassandra-dtest/pull/208]|
was (Author: adelapena):
Just rebased on top of CASSANDRA-18068:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2125]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2615/workflows/235677a7-aae1-444f-a8c3-6dba4ae3df2d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2615/workflows/f9fc47b8-ffba-4655-8e08-234006fa33ce]|
|[dtest|https://github.com/apache/cassandra-dtest/pull/208]|
> Add a new UNMASK permission
> ---
>
> Key: CASSANDRA-18069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18069
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Add a new UNMASK permission allowing users with that permission to see the
> data masked by the masking functions attached to columns introduced by
> CASSANDRA-18068, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> It would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH default(),
> birth date MASKED WITH default()
> );
>
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21');
>
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON TABLE patients TO unprivileged_user;
> > GRANT SELECT ON TABLE patients TO privileged_user;
> > GRANT UNMASK ON TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
>
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name| birth
> -+
> ale | 1900-01-01
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name | birth
> ---+
> alice | 1982-12-21
> {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-18069) Add a new UNMASK permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697019#comment-17697019
]
Andres de la Peña commented on CASSANDRA-18069:
---
Just rebased on top of CASSANDRA-18068:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2125]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2615/workflows/235677a7-aae1-444f-a8c3-6dba4ae3df2d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2615/workflows/f9fc47b8-ffba-4655-8e08-234006fa33ce]|
|[dtest|https://github.com/apache/cassandra-dtest/pull/208]|
> Add a new UNMASK permission
> ---
>
> Key: CASSANDRA-18069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18069
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Add a new UNMASK permission allowing users with that permission to see the
> data masked by the masking functions attached to columns introduced by
> CASSANDRA-18068, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> It would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH default(),
> birth date MASKED WITH default()
> );
>
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21');
>
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON TABLE patients TO unprivileged_user;
> > GRANT SELECT ON TABLE patients TO privileged_user;
> > GRANT UNMASK ON TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
>
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name| birth
> -+
> ale | 1900-01-01
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name | birth
> ---+
> alice | 1982-12-21
> {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-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697016#comment-17697016 ] Michael Semb Wever commented on CASSANDRA-18106: The former needs jdk8, the latter will need jdk11. bq. Are you saying we need a way to switch inside while running the matrix, so both these scenarios can run with their respective JDKs? Correct. bq. And that is where running them twice comes in, but they filter out invalid JDKs? Correct. But just an idea to put options on the table. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697011#comment-17697011 ] Brandon Williams commented on CASSANDRA-18106: -- But neither of those requires switching JDKs, one can be covered by 8, the other by 11. Are you saying we need a way to switch inside while running the matrix, so both these scenarios can run with their respective JDKs? And that is where running them twice comes in, but they filter out invalid JDKs? > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697003#comment-17697003
]
Michael Semb Wever commented on CASSANDRA-18106:
{quote}
bq. b) we run the python dtest upgrade tests twice and each run ignores
(filters out) upgrade paths that are not valid for the current JAVA_HOME jdk.
…how would this look exactly for the 3.11 to 5 scenario?
{quote}
There is no 3.11 to 5 scenario.
But both cassandra-4.0 and cassandra-4.1 branches will run both (python dtest)
scenarios
- 3.x to 4.x upgrade tests [past to current]
- 4.x to 5.0/trunk [current forward]
See same
[link|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py#L192-L193]
you posted above.
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
> Attachments: Screenshot 2023-03-03 at 09.24.50.png
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18303) Feature documentation lost / moved out of focus
[ https://issues.apache.org/jira/browse/CASSANDRA-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697000#comment-17697000 ] Ekaterina Dimitrova commented on CASSANDRA-18303: - Thank you [~rtib] , I noticed you attached a patch so I moved it to patch available. I will try to take a look at it tonight. CC [~mck] > Feature documentation lost / moved out of focus > --- > > Key: CASSANDRA-18303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Fix For: 4.1.x, 4.x > > > Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 > and now the documentation on the website page "Cassandra/Operating/Virtual > tables" shows an outdated version for > [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] > and > [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18296) tablehistograms add filter for data table and system table
[ https://issues.apache.org/jira/browse/CASSANDRA-18296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17697001#comment-17697001 ] Brandon Williams commented on CASSANDRA-18296: -- This all sounds reasonable to me, what do you need [~maxwellguo]? > tablehistograms add filter for data table and system table > --- > > Key: CASSANDRA-18296 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18296 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > Add some options for nodetool tablehistograms to filter the output > of System tables and data tables. > As we know if we nodetool tablehistograms all tables will be output ,but > system table 's number are too much. > Add options to filter only output data tables or system tables, together with > the already exist ks.tb lists, the output options are just fine. > It seems that tablestats got the -i option that can ignore keyspace, just add > this first, and then to see wether this can meet our needs -- This message was sent by Atlassian Jira (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-18294) die disk failure policy will not kill jvm as documented
[ https://issues.apache.org/jira/browse/CASSANDRA-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696996#comment-17696996 ] Brandon Williams commented on CASSANDRA-18294: -- The PR looks fine to me, but bq. I am trying to figure out why this has slipped. Did you figure this out, [~smiklosovic]? > die disk failure policy will not kill jvm as documented > --- > > Key: CASSANDRA-18294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18294 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Runtian Liu >Assignee: Runtian Liu >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x > > > After Cassandra has successfully starts up with disk_failure_policy die, when > encounter a file system error, Cassandra server will only throw exception > instead of shut down gossip and client transport and kill JVM. Document: > [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#disk_failure_policy] > > The reason for this is the default FS error handler is not handing policy die > correctly. Instead of shutting down gossip and native transport, it throws an > error. > > The JVMStabilityInspectorTest is passing because the error handler is not set > so no exception is thrown. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696995#comment-17696995 ] Brandon Williams commented on CASSANDRA-18106: -- bq. b) we run the python dtest upgrade tests twice and each run ignores (filters out) upgrade paths that are not valid for the current JAVA_HOME jdk. I'm not sure I understand this, how would this look exactly for the 3.11 to 5 scenario? > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > Attachments: Screenshot 2023-03-03 at 09.24.50.png > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18303) Feature documentation lost / moved out of focus
[ https://issues.apache.org/jira/browse/CASSANDRA-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18303: Test and Documentation Plan: [https://github.com/apache/cassandra/pull/2194] Status: Patch Available (was: In Progress) > Feature documentation lost / moved out of focus > --- > > Key: CASSANDRA-18303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > > Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 > and now the documentation on the website page "Cassandra/Operating/Virtual > tables" shows an outdated version for > [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] > and > [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18303) Feature documentation lost / moved out of focus
[ https://issues.apache.org/jira/browse/CASSANDRA-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18303: Fix Version/s: 4.1.x 4.x > Feature documentation lost / moved out of focus > --- > > Key: CASSANDRA-18303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Fix For: 4.1.x, 4.x > > > Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 > and now the documentation on the website page "Cassandra/Operating/Virtual > tables" shows an outdated version for > [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] > and > [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18303) Feature documentation lost / moved out of focus
[ https://issues.apache.org/jira/browse/CASSANDRA-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18303: Bug Category: Parent values: Documentation(13562) Complexity: Low Hanging Fruit Discovered By: User Report Severity: Low Assignee: Tibor Repasi Status: Open (was: Triage Needed) > Feature documentation lost / moved out of focus > --- > > Key: CASSANDRA-18303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > > Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 > and now the documentation on the website page "Cassandra/Operating/Virtual > tables" shows an outdated version for > [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] > and > [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (f527cda83 -> a40a7a8a2)
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 f527cda83 generate docs for ba88b347 new a40a7a8a2 generate docs for ba88b347 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 (f527cda83) \ N -- N -- N refs/heads/asf-staging (a40a7a8a2) 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: .../cassandra/configuration/cass_yaml_file.html| 35 + .../cassandra/configuration/cass_yaml_file.html| 35 + site-ui/build/ui-bundle.zip| Bin 4796442 -> 4796442 bytes 3 files changed, 70 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18303) Feature documentation lost / moved out of focus
[ https://issues.apache.org/jira/browse/CASSANDRA-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696978#comment-17696978 ] Tibor Repasi commented on CASSANDRA-18303: -- Politely knocking at [~e.dimitrova] > Feature documentation lost / moved out of focus > --- > > Key: CASSANDRA-18303 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Tibor Repasi >Priority: Normal > > Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 > and now the documentation on the website page "Cassandra/Operating/Virtual > tables" shows an outdated version for > [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] > and > [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18303) Feature documentation lost / moved out of focus
Tibor Repasi created CASSANDRA-18303: Summary: Feature documentation lost / moved out of focus Key: CASSANDRA-18303 URL: https://issues.apache.org/jira/browse/CASSANDRA-18303 Project: Cassandra Issue Type: Bug Components: Documentation/Website Reporter: Tibor Repasi Documentation added with CASSANDRA-17344 wasn't moved with CASSANDRA-17976 and now the documentation on the website page "Cassandra/Operating/Virtual tables" shows an outdated version for [4.1|https://cassandra.apache.org/doc/4.1/cassandra/operating/virtualtables.html] and [latest|https://cassandra.apache.org/doc/latest/cassandra/operating/virtualtables.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18071) Allow to use user-defined functions (UDF) as masking functions
[ https://issues.apache.org/jira/browse/CASSANDRA-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18071: -- Reviewers: Benjamin Lerer, Berenguer Blasi (was: Berenguer Blasi) > Allow to use user-defined functions (UDF) as masking functions > -- > > Key: CASSANDRA-18071 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18071 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1.5h > Remaining Estimate: 0h > > Allow to attach user-defined functions (UDF) to tables so they can be used as > masking functions, as defined by > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > This will be similar to the native data masking functions introduced by > CASSANDRA-17941 and attached to tables by CASSANDRA-18068. -- This message was sent by Atlassian Jira (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-18070) Add a new SELECT_MASKED permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18070:
--
Reviewers: Benjamin Lerer, Berenguer Blasi (was: Berenguer Blasi)
> Add a new SELECT_MASKED permission
> --
>
> Key: CASSANDRA-18070
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18070
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Add a table-level SELECT_MASKED permission allowing certain users to query
> but not see the unmasked columns introduced by CASSANDRA-18068, assuming that
> they also have the SELECT permission on the table, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> It would look like:
> {code}
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON ALL TABLE patients TO unprivileged_user;
> > GRANT SELECT ON ALL TABLE patients TO privileged_user;
> > GRANT SELECT_MASKED ON ALL TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> Unauthorized: Error from server: code=2100 [Unauthorized] message="User has
> no UNMASK nor SELECT_UNMASK permission on "
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE name='alice' ALLOW FILTERING;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18069) Add a new UNMASK permission
[
https://issues.apache.org/jira/browse/CASSANDRA-18069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18069:
--
Reviewers: Benjamin Lerer, Berenguer Blasi (was: Berenguer Blasi)
> Add a new UNMASK permission
> ---
>
> Key: CASSANDRA-18069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18069
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Add a new UNMASK permission allowing users with that permission to see the
> data masked by the masking functions attached to columns introduced by
> CASSANDRA-18068, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> It would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH default(),
> birth date MASKED WITH default()
> );
>
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21');
>
> > CREATE USER unprivileged_user WITH PASSWORD 'xyz';
> > CREATE USER privileged_user WITH PASSWORD 'zyx';
>
> > GRANT SELECT ON TABLE patients TO unprivileged_user;
> > GRANT SELECT ON TABLE patients TO privileged_user;
> > GRANT UNMASK ON TABLE patients TO privileged_user;
>
> > LOGIN unprivileged_user
>
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name| birth
> -+
> ale | 1900-01-01
>
> > LOGIN privileged_user
> > SELECT name, birth FROM patients WHERE
> > id=db2b372f-f91b-4537-b46b-c478f8330c29;
>
> name | birth
> ---+
> alice | 1982-12-21
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18068:
--
Fix Version/s: NA
Source Control Link: ||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2110]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2687/workflows/cf7ad885-2b3b-4164-8064-f45346914291]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/26
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
This message was sent by Atlassian Jira
(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-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696963#comment-17696963
]
Andres de la Peña commented on CASSANDRA-18068:
---
Thanks for the reviews. Committed to feature branch
[17940-trunk|https://github.com/adelapena/cassandra/tree/17940-trunk] as
[31178d2fd9042f5257f6da0698aad98c2f452789|https://github.com/apache/cassandra/pull/2193/commits/31178d2fd9042f5257f6da0698aad98c2f452789].
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
This message was sent by Atlassian Jira
(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-18068) Allow to attach native masking functions to table columns
[
https://issues.apache.org/jira/browse/CASSANDRA-18068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18068:
--
Status: Ready to Commit (was: Review In Progress)
> Allow to attach native masking functions to table columns
> -
>
> Key: CASSANDRA-18068
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18068
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 9h 40m
> Remaining Estimate: 0h
>
> Allow to attach the native masking functions added by CASSANDRA-17941 to
> table columns, as defined by
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
>
> {{CREATE TABLE}} statements would look like:
> {code}
> > CREATE TABLE patients (
> id timeuuid PRIMARY KEY,
> name text MASKED WITH partial(2, 1),
> birth date MASKED WITH default()
> );
> > INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
>
> > SELECT name, birth FROM patients;
>
> name| birth
> -+
> ale | 1900-01-01
> {code}
> {{ALTER TABLE}} statements would look like:
> {code}
> > ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> > ALTER TABLE patients ALTER name WITHOUT MASK;
> {code}
> It won't be possible to use masked columns in the WHERE and IF clauses of
> SELECT and UPDATE statements.
--
This message was sent by Atlassian Jira
(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-18302) Fix AIOOBE and improve validation messages for transaction statements
Jacek Lewandowski created CASSANDRA-18302: - Summary: Fix AIOOBE and improve validation messages for transaction statements Key: CASSANDRA-18302 URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 Project: Cassandra Issue Type: Improvement Reporter: Jacek Lewandowski Assignee: Jacek Lewandowski Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown from asCql method when validation transaction statement. In addition, asCql does not return precisely the query user entered so the whole error message can be misleading. -- This message was sent by Atlassian Jira (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-18302) Fix AIOOBE and improve validation messages for transaction statements
[ https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18302: -- Change Category: Semantic Complexity: Low Hanging Fruit Component/s: Accord Status: Open (was: Triage Needed) > Fix AIOOBE and improve validation messages for transaction statements > - > > Key: CASSANDRA-18302 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18302 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown > from asCql method when validation transaction statement. In addition, asCql > does not return precisely the query user entered so the whole error message > can be misleading. -- This message was sent by Atlassian Jira (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-17044) Refactor schema management to allow for schema source pluggability
[ https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696941#comment-17696941 ] Jacek Lewandowski commented on CASSANDRA-17044: --- [~benedict] thanks for pointing that. In CASSANDRA-18291 I'm fixing a different minor issue with schema management and I attached also a commit to fix that perf regression. If you have a moment, you can review, just a couple of lines. > Refactor schema management to allow for schema source pluggability > -- > > Key: CASSANDRA-17044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17044 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1-alpha1, 4.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The idea is decompose `Schema` into separate entities responsible for > different things. In particular extract what is related to schema storage and > synchronization into a separate class so that it is possible to create an > extension point there and store schema in a different way than > `system_schema` keyspace, for example in etcd. > This would also simplify the logic and reduce the number of special cases, > make all the things more testable and the logic of internal classes > encapsulated. -- This message was sent by Atlassian Jira (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-18291) Too early schema version change in system local table
[ https://issues.apache.org/jira/browse/CASSANDRA-18291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696908#comment-17696908 ] Jacek Lewandowski commented on CASSANDRA-18291: --- https://github.com/apache/cassandra/pull/2192 > Too early schema version change in system local table > - > > Key: CASSANDRA-18291 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18291 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.x, 4.2 > > > Schema version in the system local table is updated after the schema changes > is saved but before it is applied. > Found by [~maxtomassi] -- This message was sent by Atlassian Jira (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-18291) Too early schema version change in system local table
[ https://issues.apache.org/jira/browse/CASSANDRA-18291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18291: -- Test and Documentation Plan: regression tests Status: Patch Available (was: In Progress) > Too early schema version change in system local table > - > > Key: CASSANDRA-18291 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18291 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1.x, 4.2 > > > Schema version in the system local table is updated after the schema changes > is saved but before it is applied. > Found by [~maxtomassi] -- This message was sent by Atlassian Jira (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-18283) Enhance diagnostic nodetool tablestats output
[ https://issues.apache.org/jira/browse/CASSANDRA-18283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18283: - Reviewers: Brandon Williams > Enhance diagnostic nodetool tablestats output > - > > Key: CASSANDRA-18283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18283 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: image-2023-02-28-08-08-24-727.png > > Time Spent: 20m > Remaining Estimate: 0h > > The nodetool tablestats command lacks some available details which would be > very useful to report upon. This is especially helpful in > database-as-a-service environments where servers and their disk files are not > directly observable by users. > 1. Currently, for LCS tablestats reports useful details about the number of > sstables in each level: > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > This type of additional detail about the sstables is absent from STCS and > TWCS as it only reports the table count. > 1a) For STCS, tablestats should report the max sstable file size on disk. > This is useful to know if compaction has failed due to disk space or if a > forced compaction created a jumbo table. > 1b) For TWCS, tablestats should report the min & max timestamp, and duration > of the sstables representing windows. This is useful to know if > out-of-window writes or rows w/out a TTL have lead many more sstables on disk > than expected by the time window configuration. > STCs example: > SSTable count: 6635 > SSTable STCS max size: 122,000,000,000 > STCs example: > SSTable count: 6635 > SSTables Time Window 15 DAYS, max duration : 362d 7h 16m 49s > 2. While tablestats reports both memtable and disk file sstable statistics. > It is useful these are in the same command, but it would clarify the output > to separate mem vs disk into two sections > i.e., > -- File statistics > SSTable count: 6635 > SSTables in each level: [1, 9, 98, 805, 5722, 0, 0, 0, 0] > -- Memtable statistics > Bloom filter false positives: 12184123 > Bloom filter false ratio: 0.07203 > Bloom filter space used: 16874424 > Bloom filter off heap memory used: 16821344 > Index summary off heap memory used: 7525546 > Space used (live): 1324067896238 > 3. Read / Write count should also be reported as a ratio, such as: > Local read count: 202961459 > Local write count: 40554481 > Local read/write ratio: 5:1 > Local read latency: 1.957 ms > Local write count: 40554481 > Local write latency: 0.040 ms -- This message was sent by Atlassian Jira (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-18268) Log completed status with cleanup and garbagecollect operations
[ https://issues.apache.org/jira/browse/CASSANDRA-18268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18268: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic) > Log completed status with cleanup and garbagecollect operations > --- > > Key: CASSANDRA-18268 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18268 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Kan Maung >Assignee: Milan Krisko >Priority: Normal > > Whenever a cleanup or garbagecollect operation is issued from nodetool, there > is no log statuses for the start and end of the operation at the node level > although statuses on individual sstables are captured. Start can be inferred, > but it is difficult to know when the operation has completed because there is > no log message. > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable1 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable1 successfully > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:353 - > Starting Remove deleted data for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:364 - No > sstables to GARBAGE_COLLECT for keyspace1.sstable2 > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 - > Finished Remove deleted data for keyspace1.sstable2 successfully > > This improvement proposes adding additional for start and end statuses log > messages for the above operation at the node level. I.e., > > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Starting GARBAGE_COLLECT > …. > [INFO ] cluster_id=5 ip_address=127.1.1.1 CompactionManager.java:395 – > Completed GARBAGE_COLLECT -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696887#comment-17696887 ] Brandon Williams commented on CASSANDRA-18301: -- Specifying in the yaml simplifies things and makes sense to me. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian 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 dependabot/npm_and_yarn/site-ui/minimist-1.2.8 created (now 38b85a8cd)
This is an automated email from the ASF dual-hosted git repository. github-bot pushed a change to branch dependabot/npm_and_yarn/site-ui/minimist-1.2.8 in repository https://gitbox.apache.org/repos/asf/cassandra-website.git at 38b85a8cd Bump minimist from 1.2.5 to 1.2.8 in /site-ui No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696814#comment-17696814 ] Jacek Lewandowski commented on CASSANDRA-18301: --- maybe let it be configured in cassandra yaml and overridden in schema ? > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696811#comment-17696811 ] maxwellguo commented on CASSANDRA-18301: yes，It will introduce some new params, so we used the extensions map in TableParams to avoid these problems. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696808#comment-17696808 ] Jacek Lewandowski commented on CASSANDRA-18301: --- well, it is possible, but IMHO it is not necessary. In particular - wouldn't it introduce some schema incompatibility by adding a new param? anyway, I'm open to suggestions > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696806#comment-17696806 ] maxwellguo commented on CASSANDRA-18301: yeah, in casandra.yaml is ok . Is it necessary to make this feature table level ? > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16203: -- Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pull/2191 I have tested this via "NetworkTopologyStrategy" test which I made parametrized where both NTS and this strategy is tested. There is one test which is not running which tests "the old algorithm" NTS is compatible with when that test was written (because NTS was itself implementing some improvements) but this strategy is not compatible with that any more as it places replicas differently. Apart from that, all tests are compatible with NTS way of doing things. > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696804#comment-17696804 ] Jacek Lewandowski commented on CASSANDRA-18301: --- ah, ok, I was thinking that it could be just in `cassandra.yaml`. Especially that CEP-17 is merged and it lets you define multiple formats so you would choose a target version for each format. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-16203: - Assignee: Stefan Miklosovic (was: Sumanth Pasupuleti) > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696802#comment-17696802 ] maxwellguo commented on CASSANDRA-18301: Not opensource cassandra ~~~,just explain the similar solutions for common needs. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[
https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696799#comment-17696799
]
Jacek Lewandowski commented on CASSANDRA-18301:
---
{quote}we just have an attribute for the file version both at schema level and
cluster level.{quote}
where?
> Let the user select the sstable version to write
>
>
> Key: CASSANDRA-18301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18301
> Project: Cassandra
> Issue Type: New Feature
> Components: Local/Config, Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
--
This message was sent by Atlassian Jira
(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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696797#comment-17696797 ] maxwellguo commented on CASSANDRA-18301: So how could user select the sstable version ? When they doing cql write with an attribute or some other cql grammar？ we just have an attribute for the file version both at schema level and cluster level. > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
Jacek Lewandowski created CASSANDRA-18301: - Summary: Let the user select the sstable version to write Key: CASSANDRA-18301 URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 Project: Cassandra Issue Type: New Feature Components: Local/Config, Local/SSTable Reporter: Jacek Lewandowski -- This message was sent by Atlassian Jira (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-18301) Let the user select the sstable version to write
[ https://issues.apache.org/jira/browse/CASSANDRA-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski reassigned CASSANDRA-18301: - Assignee: Jacek Lewandowski > Let the user select the sstable version to write > > > Key: CASSANDRA-18301 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18301 > Project: Cassandra > Issue Type: New Feature > Components: Local/Config, Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > -- This message was sent by Atlassian Jira (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-18300) The user should be able to try the new version with the ability to go back
Jacek Lewandowski created CASSANDRA-18300: - Summary: The user should be able to try the new version with the ability to go back Key: CASSANDRA-18300 URL: https://issues.apache.org/jira/browse/CASSANDRA-18300 Project: Cassandra Issue Type: Epic Reporter: Jacek Lewandowski List of all the issues, improvements, assumptions and other things we should consider to allow the user to go back to the previous version without problems. -- This message was sent by Atlassian Jira (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-17056) CEP-17 – Pluggable SSTable format (SSTable format API)
[ https://issues.apache.org/jira/browse/CASSANDRA-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-17056: -- Fix Version/s: 4.2 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/b7e1e44a909c3a1d11e9c387db680c74d31b879f Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-17 – Pluggable SSTable format (SSTable format API) > -- > > Key: CASSANDRA-17056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17056 > Project: Cassandra > Issue Type: New Feature > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.2 > > Time Spent: 18h 40m > Remaining Estimate: 0h > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API -- This message was sent by Atlassian 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] branch trunk updated: Fix assertion in offline_tools_test.py
This is an automated email from the ASF dual-hosted git repository.
jlewandowski pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 17f67484 Fix assertion in offline_tools_test.py
17f67484 is described below
commit 17f67484f4597e223a669dda4d52fb2cc2250ddf
Author: Jacek Lewandowski
AuthorDate: Thu Feb 16 13:17:13 2023 +0100
Fix assertion in offline_tools_test.py
patch by Jacek Lewandowski, reviewed by Branimir Lambov for CASSANDRA-17056
---
offline_tools_test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/offline_tools_test.py b/offline_tools_test.py
index d8a0e73e..9b1cfabc 100644
--- a/offline_tools_test.py
+++ b/offline_tools_test.py
@@ -311,7 +311,7 @@ class TestOfflineTools(Tester):
(out, error, rc) = node1.run_sstableverify("keyspace1",
"standard1", options=options)
assert False, "sstable verify did not fail;
rc={}\nout={}\nerr={}".format(str(rc), out, error)
except ToolError as e:
-m = re.match("(?ms).*Corrupted SSTable : (?P\S+)", str(e))
+m = re.match("(?ms).*Corrupted file: integrity check .* failed for
(?P\S+?):.*", str(e))
assert m is not None, str(e)
# MacOS might use the "private" prefix.
assert
os.path.normcase(m.group('sstable')).replace("/private/var/folders",
"/var/folders") == sstable1
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
