[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476514#comment-17476514
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/15/22, 3:44 AM:
---
The [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] is
ready for final round in my opinion. Circle CI run
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1270/workflows/ecf6b25a-8849-4605-af66-9fbd53281629].
(Only Java 8 until we have +1, then I will have also the Java 11; also I
submitted a Jenkins run, see below)
All three branches -
[CCM|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234],
[Cassandra|https://github.com/ekaterinadimitrova2/cassandra/tree/15234-take2-review]
and [DTest
repo|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-take2]
were rebased and any outstanding issues fixed.
+*Exceptions:*+
* The VT Settings related tests are failing because of the issue I mentioned
in my previous comment around _key_cache_save_period, row_cache_save_period and
counter_cache_save_period._
* There are a few tests failing with byteman related issues. I suspect
CircleCI might be acting weird. The tests complete fine locally. I just pushed
a run in Jenkins
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1370/] which I
will double check tomorrow.
was (Author: e.dimitrova):
The [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] is
ready for final round in my opinion.
All three branches -
[CCM|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234],
[Cassandra|https://github.com/ekaterinadimitrova2/cassandra/tree/15234-take2-review]
and [DTest
repo|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-take2]
were rebased and any outstanding issues fixed.
+*Exceptions:*+
* The VT Settings related tests are failing because of the issue I mentioned
in my previous comment around _key_cache_save_period, row_cache_save_period and
counter_cache_save_period._
* There are a few tests failing with byteman related issues. I suspect
CircleCI might be acting weird. The tests complete fine locally. I just pushed
a run in Jenkins
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1370/] which I
will double check tomorrow.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476514#comment-17476514
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
The [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] is
ready for final round in my opinion.
All three branches -
[CCM|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234],
[Cassandra|https://github.com/ekaterinadimitrova2/cassandra/tree/15234-take2-review]
and [DTest
repo|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-take2]
were rebased and any outstanding issues fixed.
+*Exception:*+
* The VT Settings related tests are failing because of the issue I mentioned
in my previous comment around _key_cache_save_period, row_cache_save_period and
counter_cache_save_period._
* There are a few tests failing with byteman related issues. I suspect
CircleCI might be acting weird. The tests complete fine locally. I just pushed
a run in Jenkins
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1370/] which I
will double check tomorrow.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476514#comment-17476514
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/15/22, 3:42 AM:
---
The [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] is
ready for final round in my opinion.
All three branches -
[CCM|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234],
[Cassandra|https://github.com/ekaterinadimitrova2/cassandra/tree/15234-take2-review]
and [DTest
repo|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-take2]
were rebased and any outstanding issues fixed.
+*Exceptions:*+
* The VT Settings related tests are failing because of the issue I mentioned
in my previous comment around _key_cache_save_period, row_cache_save_period and
counter_cache_save_period._
* There are a few tests failing with byteman related issues. I suspect
CircleCI might be acting weird. The tests complete fine locally. I just pushed
a run in Jenkins
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1370/] which I
will double check tomorrow.
was (Author: e.dimitrova):
The [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] is
ready for final round in my opinion.
All three branches -
[CCM|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234],
[Cassandra|https://github.com/ekaterinadimitrova2/cassandra/tree/15234-take2-review]
and [DTest
repo|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-take2]
were rebased and any outstanding issues fixed.
+*Exception:*+
* The VT Settings related tests are failing because of the issue I mentioned
in my previous comment around _key_cache_save_period, row_cache_save_period and
counter_cache_save_period._
* There are a few tests failing with byteman related issues. I suspect
CircleCI might be acting weird. The tests complete fine locally. I just pushed
a run in Jenkins
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1370/] which I
will double check tomorrow.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Reviewers: Benjamin Lerer, Caleb Rackliffe, David Capwell, Michael Semb
Wever (was: Benjamin Lerer, Caleb Rackliffe, David Capwell)
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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 (a32b887 -> e675252)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. omit a32b887 generate docs for 65033abc new e675252 generate docs for 65033abc 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 (a32b887) \ N -- N -- N refs/heads/asf-staging (e675252) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-6897) Add checksum to the Summary File and Bloom Filter file of SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu reassigned CASSANDRA-6897: - Assignee: Shailaja Koppu > Add checksum to the Summary File and Bloom Filter file of SSTables > -- > > Key: CASSANDRA-6897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6897 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Adam Hattrell >Assignee: Shailaja Koppu >Priority: Normal > > Could we add a checksum to the Summary file and filter file of the SSTable. > Since reads the whole bloom filter before actually reading data, it seems > like it would make sense to checksum the bloom filter to make sure there is > no corruption there. Same is true with the summary file. The core of our > question is, can you add checksumming to all elements of the SSTable so if we > read anything corrupt we immediately see a failure? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17084:
-
Reviewers: Berenguer Blasi (was: Berenguer Blasi, Brandon Williams)
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17084:
-
Since Version: NA
Source Control Link:
https://github.com/apache/cassandra/commit/76f8333e9b9c89f029dd586273d5d42fdaf676dd
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks!
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17084:
-
Reviewers: Berenguer Blasi, Brandon Williams (was: Berenguer Blasi)
Status: Review In Progress (was: Patch Available)
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17084:
-
Status: Ready to Commit (was: Review In Progress)
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: add test for starting with relative dirs
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/trunk by this push:
new 6e756b3 add test for starting with relative dirs
6e756b3 is described below
commit 6e756b31f1c3dbeb34a12ff8d999ff992f8d29b1
Author: Brandon Williams
AuthorDate: Tue Dec 7 14:30:25 2021 -0600
add test for starting with relative dirs
Patch by brandonwilliams, reviewed by bereng for CASSANDRA-17084
---
configuration_test.py | 14 ++
1 file changed, 14 insertions(+)
diff --git a/configuration_test.py b/configuration_test.py
index ad875cb..235cf7c 100644
--- a/configuration_test.py
+++ b/configuration_test.py
@@ -2,6 +2,7 @@ import os
import logging
import parse
import pytest
+import tempfile
from cassandra.concurrent import execute_concurrent_with_args
@@ -104,6 +105,19 @@ class TestConfiguration(Tester):
write_to_trigger_fsync(session, 'ks', 'tab')
assert commitlog_size(node) > init_size, "ALTER KEYSPACE was not
respected"
+def test_relative_paths(self):
+"""
+@jira_ticket CASSANDRA-17084
+"""
+self.cluster.populate(1)
+node1 = self.cluster.nodelist()[0]
+cassdir = tempfile.mkdtemp()
+os.mkdir(os.path.join(cassdir, 'bin'))
+os.chdir(cassdir)
+node1.set_configuration_options({'commitlog_directory':
'bin/../data/commitlog', 'data_file_directories': ['bin/../data/data']})
+self.cluster.start()
+self.cluster.stop()
+
def overlapping_data_folders(self):
"""
@jira_ticket CASSANDRA-10902
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Use abolute path when checking file stores
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 76f8333 Use abolute path when checking file stores
76f8333 is described below
commit 76f8333e9b9c89f029dd586273d5d42fdaf676dd
Author: Brandon Williams
AuthorDate: Tue Dec 7 16:32:45 2021 -0600
Use abolute path when checking file stores
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17084
---
src/java/org/apache/cassandra/io/util/PathUtils.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/java/org/apache/cassandra/io/util/PathUtils.java
b/src/java/org/apache/cassandra/io/util/PathUtils.java
index 690222f..effd6fe 100644
--- a/src/java/org/apache/cassandra/io/util/PathUtils.java
+++ b/src/java/org/apache/cassandra/io/util/PathUtils.java
@@ -631,7 +631,7 @@ public final class PathUtils
{
try
{
-Path ancestor = findExistingAncestor(path.normalize());
+Path ancestor =
findExistingAncestor(path.toAbsolutePath().normalize());
if (ancestor == null)
{
orElse.accept(new NoSuchFileException(path.toString()));
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476301#comment-17476301
]
Benedict Elliott Smith commented on CASSANDRA-17164:
{quote}Is there any location where the algorithm is described in detail?
{quote}
The documentation that is present sort of assumes you are familiar with the
prior implementation of Paxos, and we pepper in justifications at each place
where a novel approach is taken. I will try to put together some overview
markdown documentation over the coming week. In the meantime:
{quote}the use of voting quorum that is not selected only among the replicas
that accepted a ballot
{quote}
I think this is actually the typical way of implementing Classic Paxos, even
though Lamport's paper seems to suggest you must only contact the nodes that
responded to the prepare (there may be something else specific about his
formulation that necessitates this, I forget, as I dislike his writings on the
topic). This is corroborated by [Heidi Howard's
dissertation|https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-935.pdf], which
was the easiest place I could find a straight-forward formulation of Classic
Paxos besides that of Lamport. See Algorithm 3 on Page 30.
{quote}the use of "most recent commit" as a voting session identifier
{quote}
I don't quite follow what you mean by this, as this is not limited to "most
recent commit", but a ballot directly maps to the instance id of classic paxos,
it just avoids pre-splitting the range of integers.
{quote}the sharing of ballot numbers between sessions and rejection/acceptance
based solely on ballot numbers which may belong to a different voting session
{quote}
Could you explain what you are referring to here? I think this is all standard
stuff for Paxos, we're again just recording the most recently used instance
number for each register.
{quote}advancing voting sessions without committing empty proposals
{quote}
The final commit phase is only required to ensure any "decree" (decision) is
disseminated. If we have proposed that no decree be made, there is nothing to
disseminate, and nothing to complete if another transaction encounters it. This
is in some ways an artefact of the feature of Cassandra's implementation, that
we initiate a paxos round without knowing if it will do anything, though this
feature would I suppose be present for read-only operations anyway.
{quote}replicas skipping voting sessions because of stale participant refresh
{quote}
There's two possible things you mean by this. I think you are referring to the
situation where we send a commit and then continue with the ballot we have
already prepared? In which case I'm not sure this is really in conflict with
any formulation I've seen, which tends to gloss over handling of {_}commit{_},
and I think may arise solely from the particulars of Cassandra - we are not
updating a register, but are agreeing a delta, and only disseminate this to any
majority (that may be different from the one that received any prior delta),
and so we must ensure that each _Commit_ is witnessed by a majority so that the
complete register state may be constructed from any majority. In normal
formulations the register is overwritten, so I don't think the _Commit_ even
needs to be received if it is superseded by another {_}Commit{_}, and I think
many formulations ignore it entirely as a result.
Anyway to justify it seems pretty straightforward: if any other command were to
supersede us we would fail the _Accept_ phase, and if not then by updating the
_MostRecentCommit_ register we know precisely what the register state is on the
node, and it is equivalent to having received this response in the first place,
so we may proceed safely.
{quote}read vs write promises
{quote}
This is just a very simple formulation of operation commutativity. We linearise
writes with writes and reads, but we do not linearise reads with each other
since they are commutative. So any read operation only consults the write
registers, but updates the read registers, whereas writes update the write
registers and consult both.
{quote}the handling of range movements
{quote}
Fair, this is quite complex, and we should have already put in an overview
here. In simple terms, each node tracks those operations that have been
witnessed but are not known to have committed. Each node is able to coordinate
the completion of these operations, either by invalidating them, committing
them, or witnessing something newer. By performing this on a majority of nodes
we are able to ensure that all operations that may have reached a decision
prior to this mechanism being invoked are now committed to a majority of nodes
in their base table. By performing this after a node becomes pending but before
streaming begins we ensure that a new node was either already participating in
any operation and
[jira] [Comment Edited] (CASSANDRA-17225) Add a virtual table for exposing batch metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476300#comment-17476300
]
Ekaterina Dimitrova edited comment on CASSANDRA-17225 at 1/14/22, 5:46 PM:
---
Overall the latest version LGTM. I left only one formatting comment. We need to
add CHANGES.txt and NEWS.txt entries but we often do that on commit too.
I can submit full CI run after [~blerer] also approves the latest version.
Thank you for your work [~burmanm] !
was (Author: e.dimitrova):
Overall the latest version LGTM. I left only one formatting comment. We need to
add CHANGES.txt and NEW.txt entries but we often do that on commit too.
I can submit full CI run after [~blerer] also approves the latest version.
Thank you for your work [~burmanm] !
> Add a virtual table for exposing batch metrics
> --
>
> Key: CASSANDRA-17225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17225
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Michael Burman
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within BatchMetrics that provide metrics
> about related to the different types of Batches being executed. We should
> expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example of virtual table implementation and to {{TableMetricTables}} for
> how Histogram metrics can be exposed. The new table will need to be
> registered in {{SystemViewsKeyspace}}.
> Some unit tests should be added. For some example of virtual table tests you
> can look at {{SystemPropertiesTableTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17225) Add a virtual table for exposing batch metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476300#comment-17476300
]
Ekaterina Dimitrova commented on CASSANDRA-17225:
-
Overall the latest version LGTM. I left only one formatting comment. We need to
add CHANGES.txt and NEW.txt entries but we often do that on commit too.
I can submit full CI run after [~blerer] also approves the latest version.
Thank you for your work [~burmanm] !
> Add a virtual table for exposing batch metrics
> --
>
> Key: CASSANDRA-17225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17225
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Michael Burman
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within BatchMetrics that provide metrics
> about related to the different types of Batches being executed. We should
> expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example of virtual table implementation and to {{TableMetricTables}} for
> how Histogram metrics can be exposed. The new table will need to be
> registered in {{SystemViewsKeyspace}}.
> Some unit tests should be added. For some example of virtual table tests you
> can look at {{SystemPropertiesTableTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476269#comment-17476269 ] Branimir Lambov commented on CASSANDRA-17164: - Most of this is inherited from the earlier implementation, but I still can't find a description that explains why we can trust these modifications. CASSANDRA-5062 discusses some of them, but still leaves quite a bit of doubt about their correctness (to me at least). > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17164) CEP-14: Paxos Improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476253#comment-17476253 ] Branimir Lambov commented on CASSANDRA-17164: - Is there any location where the algorithm is described in detail? I find it pretty hard to follow the algorithm steps and decision points, as they are spread among a multitude of classes and files. There are quite a few non-trivial differences with the basic Paxos algorithm which need to be laid out and have some explanation of why they are safe: - the use of voting quorum that is not selected only among the replicas that accepted a ballot - the use of "most recent commit" as a voting session identifier - the sharing of ballot numbers between sessions and rejection/acceptance based solely on ballot numbers which may belong to a different voting session - advancing voting sessions without committing empty proposals - replicas skipping voting sessions because of stale participant refresh - read vs write promises - the handling of range movements - state expiration I think this piece of work will benefit tremendously from in-tree markdown documentation that describes the above. > CEP-14: Paxos Improvements > -- > > Key: CASSANDRA-17164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17164 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Coordination, Consistency/Repair >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > Fix For: 4.1 > > > This ticket encompasses work for [CEP-14| > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-11370) Display sstable count per level according to repair status on nodetool tablestats
[ https://issues.apache.org/jira/browse/CASSANDRA-11370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shailaja Koppu reassigned CASSANDRA-11370: -- Assignee: Shailaja Koppu > Display sstable count per level according to repair status on nodetool > tablestats > - > > Key: CASSANDRA-11370 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11370 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Paulo Motta (Deprecated) >Assignee: Shailaja Koppu >Priority: Low > Labels: lhf > > After CASSANDRA-8004 we still display sstables in each level on nodetool > tablestats as if we had a single compaction strategy, while we have one > strategy for repaired and another for unrepaired data. > We should split display into repaired and unrepaired set, so this: > SSTables in each level: [2, 20/10, 15, 0, 0, 0, 0, 0, 0] > Would become: > SSTables in each level (repaired): [1, 10, 0, 0, 0, 0, 0, 0, 0] > SSTables in each level (unrepaired): [1, 10, 15, 0, 0, 0, 0, 0, 0] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476098#comment-17476098
]
Andres de la Peña commented on CASSANDRA-17243:
---
I have just added this entry to NEWS.txt in all branches:
{code:java}
The config properties for setting the streaming throughput
`stream_throughput_outbound_megabits_per_sec` and
`inter_dc_stream_throughput_outbound_megabits_per_sec` were incorrectly
interpreted as mebibits. This has
been fixed by CASSANDRA-17243, so the values for these properties will now
indicate a throughput ~4.6% lower than
what was actually applied in previous versions. This also affects the setters
and getters for these properties in
the JMX MBean `org.apache.cassandra.db:type=StorageService` and the nodetool
commands `set/getstreamthroughput`
and `set/getinterdcstreamthroughput`.
{code}
We don't need to mention
{{entire_sstable_stream_throughput_outbound_megabits_per_sec}} nor
{{entire_sstable_inter_dc_stream_throughput_outbound_megabits_per_sec}} because
they have been recently added to 4.1, and they don't exist on previous versions.
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17228) WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why We Need Them"
[ https://issues.apache.org/jira/browse/CASSANDRA-17228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476070#comment-17476070 ] Michael Semb Wever commented on CASSANDRA-17228: live at https://cassandra.apache.org/_/blog/Configurable-Storage-Ports-and-Why-We-Need-Them.html > WEBSITE - December 2021 blog post titled "Configurable Storage Ports and Why > We Need Them" > -- > > Key: CASSANDRA-17228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17228 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > Attachments: c17228-01-blog_post.png > > > This ticket is to capture the work associated with publishing the December > 2021 blog post for "Configurable Storage Ports and Why We Need Them" > If this blog cannot be published by the *December 28, 2021 publish date*, > please contact me, suggest changes, or correct the date yourself when > possible in the pull request for the appropriate time that the blog will go > live (on blog.adoc and in the blog). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (32b4538 -> a32b887)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard 32b4538 generate docs for b70dcb85
add 8178b6c Added tl;dr to README.md
add 65033ab December blog post titled: "Configurable Storage Ports and
Why We Need Them"
add a32b887 generate docs for 65033abc
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 (32b4538)
\
N -- N -- N refs/heads/asf-site (a32b887)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
README.md | 40 -
...d-why-we-need-them-unsplash-bernard-hermant.jpg | Bin 0 -> 271007 bytes
content/_/blog.html| 26 -
...urable-Storage-Ports-and-Why-We-Need-Them.html} | 54 -
.../cassandra/configuration/cass_yaml_file.html| 15 +
.../4.1/cassandra/tools/nodetool/bootstrap.html| 6 +-
.../doc/4.1/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.1/cassandra/tools/nodetool/nodetool.html | 6 +-
.../4.1/cassandra/tools/nodetool/repair_admin.html | 64 ++---
.../cassandra/configuration/cass_yaml_file.html| 15 +
.../latest/cassandra/tools/nodetool/bootstrap.html | 6 +-
.../latest/cassandra/tools/nodetool/import.html| 6 +-
.../latest/cassandra/tools/nodetool/nodetool.html | 6 +-
.../cassandra/tools/nodetool/repair_admin.html | 64 ++---
.../cassandra/configuration/cass_yaml_file.html| 15 +
.../trunk/cassandra/tools/nodetool/bootstrap.html | 6 +-
.../doc/trunk/cassandra/tools/nodetool/import.html | 6 +-
.../trunk/cassandra/tools/nodetool/nodetool.html | 6 +-
.../cassandra/tools/nodetool/repair_admin.html | 64 ++---
content/search-index.js| 2 +-
...d-why-we-need-them-unsplash-bernard-hermant.jpg | Bin 0 -> 271007 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 28 -
...gurable-Storage-Ports-and-Why-We-Need-Them.adoc | 42 ++
site-ui/build/ui-bundle.zip| Bin 4740057 -> 4740057
bytes
24 files changed, 328 insertions(+), 155 deletions(-)
create mode 100644
content/_/_images/blog/configurable-storage-ports-and-why-we-need-them-unsplash-bernard-hermant.jpg
copy content/_/blog/{Join-Cassandra-GSoC-2021.html =>
Configurable-Storage-Ports-and-Why-We-Need-Them.html} (68%)
create mode 100644
site-content/source/modules/ROOT/images/blog/configurable-storage-ports-and-why-we-need-them-unsplash-bernard-hermant.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Configurable-Storage-Ports-and-Why-We-Need-Them.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16801) PasswordObfuscator should not assume PASSWORD is the last item in the WITH clause
[
https://issues.apache.org/jira/browse/CASSANDRA-16801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476054#comment-17476054
]
Benjamin Lerer commented on CASSANDRA-16801:
+1
> PasswordObfuscator should not assume PASSWORD is the last item in the WITH
> clause
> -
>
> Key: CASSANDRA-16801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16801
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Caleb Rackliffe
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> CASSANDRA-16669 introduced support for obfuscating passwords for audit log
> statements, but there are a few cases where the obfuscation logic can destroy
> some of the contents of the original/provided string.
> ex. This is perfectly valid...
> {noformat}
> WITH LOGIN = false AND PASSWORD = 'bar' AND SUPERUSER = false
> {noformat}
> ...but calling obfuscate() on it will produce...
> {noformat}
> WITH LOGIN = false AND PASSWORD ***
> {noformat}
> -We should be able to create a reasonable RegEx and use String#replaceAll()
> to both simplify and correct PasswordObfuscator#obfuscate().-
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
