[jira] [Commented] (CASSANDRA-19771) NodeTool gcstats should have JSON output option
[
https://issues.apache.org/jira/browse/CASSANDRA-19771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865564#comment-17865564
]
Tibor Repasi commented on CASSANDRA-19771:
--
I think this could be addressed as part of CASSANDRA-17445, that do you think
[~mmuzaf]?
> NodeTool gcstats should have JSON output option
> ---
>
> Key: CASSANDRA-19771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19771
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Dhanush Ananthkar
>Priority: Normal
>
> *nodetool help gcstats* does not show a JSON option
>
> {noformat}
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pp | --print-port)] [(-pw | --password
> )]
> [(-pwf | --password-file
> )]
> [(-u | --username )] gcstats
> {noformat}
>
--
This message was sent by Atlassian Jira
(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-17445) Library airlift/airline has been deprecated
[ https://issues.apache.org/jira/browse/CASSANDRA-17445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861249#comment-17861249 ] Tibor Repasi commented on CASSANDRA-17445: -- Because of the size of the work, I'd suggest to do it in separate iterations for every tool, with their own feature branch and merge it before as soon as possible. That would allow the iterations to keep shorter in time and lower the risk of concurrent changes between trunk and feature branches, while provide agility. I will check out your PR and have a look on it. > Library airlift/airline has been deprecated > --- > > Key: CASSANDRA-17445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17445 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Tibor Repasi >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The [airlift/airline|https://github.com/airlift/airline] library has been > deprecated and is not maintained since [8 Jun > 2021|https://github.com/airlift/airline/commit/ae3d7e103bdc140969bde944d4ba09345d663a61]. > It is used in many tools and some tests of Cassandra which should be > reviewed. > Tools using that library: > * org.apache.cassandra.tools.JMXTool > * org.apache.cassandra.tools.NodeTool > * org.apache.cassandra.stress.Compaction > * org.apache.cassandra.fqltool.FullQueryLogTool > Tests using it: > * org.apache.cassandra.simulator.SimulationRunner > Alternatives (as suggested in the depreciation notice): > * [Airline 2|https://rvesse.github.io/airline/] > * [picocli|https://picocli.info] -- This message was sent by Atlassian Jira (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-19706) Enable color nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-19706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856598#comment-17856598
]
Tibor Repasi commented on CASSANDRA-19706:
--
Absolutely, [~mmuzaf] do you need a hand on reengineering to PiloCLI? I'd be
happy about these kind of improvements.
> Enable color nodetool status output
> ---
>
> Key: CASSANDRA-19706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19706
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To improve human readability of {{nodetool status}}, the following patch adds
> an option that enables status lines to be printed augmented by different
> colors. Warning color - yellow by default - is used for a node joining,
> leaving or moving and alert color - red by default - is used for nodes which
> are not up.
> The option {{\-c}} or {{\-\-color}} enables the feature. Alternatively, the
> environment variable {{NODETOOL_COLOR_OUTPUT}} set {{true}} will enable it by
> default. Further environment variables {{NODETOOL_WARNING_COLOR}} and
> {{NODETOOL_ALERT_COLOR}} allow to override the default colors by setting to
> values 30-37 of the standard ANSI codes for foreground color.
--
This message was sent by Atlassian Jira
(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-19706) Enable colour nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-19706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-19706:
-
Description:
To improve human readability of {{nodetool status}}, the following patch adds
an option that enables status lines to be printed augmented by different
colors. Warning color - yellow by default - is used for a node joining, leaving
or moving and alert color - red by default - is used for nodes which are not up.
The option {{\-c}} or {{\-\-color}} enables the feature. Alternatively, the
environment variable {{NODETOOL_COLOR_OUTPUT}} set {{true}} will enable it by
default. Further environment variables {{NODETOOL_WARNING_COLOR}} and
{{NODETOOL_ALERT_COLOR}} allow to override the default colors by setting to
values 30-37 of the standard ANSI codes for foreground color.
was:
To improve human readability of {{nodetool status}}, the following patch adds
an option that enables status lines to be printed augmented by different
colors. Warning color - yellow by default - is used for a node joining, leaving
or moving and alert color - red by default - is used for nodes which are not up.
The option {{-c}} or {{--color}} enables the feature. Alternatively, the
environment variable {{NODETOOL_COLOR_OUTPUT}} set {{true}} will enable it by
default. Further environment variables {{NODETOOL_WARNING_COLOR}} and
{{NODETOOL_ALERT_COLOR}} allow to override the default colors by setting to
values 30-37 of the standard ANSI codes for foreground color.
> Enable colour nodetool status output
>
>
> Key: CASSANDRA-19706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19706
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To improve human readability of {{nodetool status}}, the following patch adds
> an option that enables status lines to be printed augmented by different
> colors. Warning color - yellow by default - is used for a node joining,
> leaving or moving and alert color - red by default - is used for nodes which
> are not up.
> The option {{\-c}} or {{\-\-color}} enables the feature. Alternatively, the
> environment variable {{NODETOOL_COLOR_OUTPUT}} set {{true}} will enable it by
> default. Further environment variables {{NODETOOL_WARNING_COLOR}} and
> {{NODETOOL_ALERT_COLOR}} allow to override the default colors by setting to
> values 30-37 of the standard ANSI codes for foreground color.
--
This message was sent by Atlassian Jira
(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-19706) Enable color nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-19706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-19706:
-
Summary: Enable color nodetool status output (was: Enable colour nodetool
status output)
> Enable color nodetool status output
> ---
>
> Key: CASSANDRA-19706
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19706
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To improve human readability of {{nodetool status}}, the following patch adds
> an option that enables status lines to be printed augmented by different
> colors. Warning color - yellow by default - is used for a node joining,
> leaving or moving and alert color - red by default - is used for nodes which
> are not up.
> The option {{\-c}} or {{\-\-color}} enables the feature. Alternatively, the
> environment variable {{NODETOOL_COLOR_OUTPUT}} set {{true}} will enable it by
> default. Further environment variables {{NODETOOL_WARNING_COLOR}} and
> {{NODETOOL_ALERT_COLOR}} allow to override the default colors by setting to
> values 30-37 of the standard ANSI codes for foreground color.
--
This message was sent by Atlassian Jira
(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-19706) Enable colour nodetool status output
Tibor Repasi created CASSANDRA-19706:
Summary: Enable colour nodetool status output
Key: CASSANDRA-19706
URL: https://issues.apache.org/jira/browse/CASSANDRA-19706
Project: Cassandra
Issue Type: Improvement
Components: Tool/nodetool
Reporter: Tibor Repasi
To improve human readability of {{nodetool status}}, the following patch adds
an option that enables status lines to be printed augmented by different
colors. Warning color - yellow by default - is used for a node joining, leaving
or moving and alert color - red by default - is used for nodes which are not up.
The option {{-c}} or {{--color}} enables the feature. Alternatively, the
environment variable {{NODETOOL_COLOR_OUTPUT}} set {{true}} will enable it by
default. Further environment variables {{NODETOOL_WARNING_COLOR}} and
{{NODETOOL_ALERT_COLOR}} allow to override the default colors by setting to
values 30-37 of the standard ANSI codes for foreground color.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833835#comment-17833835
]
Tibor Repasi commented on CASSANDRA-19110:
--
Thank You.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.5, 5.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833287#comment-17833287
]
Tibor Repasi commented on CASSANDRA-19110:
--
Did it. Filed the PRs for trunk, 5.0, 4.1, 4.0 and 3.11.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833216#comment-17833216
]
Tibor Repasi commented on CASSANDRA-19110:
--
They are referring to 42x repository, which has been bumped to 50x ... however,
on the download page 41x is referred as the latest stable release. I'd like to
have that consistent, but at which one? Moreover, the cassandra repository has
multiple branches, should we update all of them? To their actual repo? ...
would make sense to me.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833209#comment-17833209
]
Tibor Repasi commented on CASSANDRA-19110:
--
Created [PR#268|https://github.com/apache/cassandra-website/pull/268] to remove
the usage of apt-key from website's download page.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833147#comment-17833147
]
Tibor Repasi edited comment on CASSANDRA-19110 at 4/2/24 11:35 AM:
---
{quote}Keys in /etc/apt/keyrings are not trusted globally. This is in contrast
to the keys in /etc/apt/trusted.gpg.d. I do not know about the ones in
/usr/share/keyring – they might be){quote}
Those in {{/usr/share/keyrings}} aren't globally trusted either.
{quote}So /etc/apt/keysrings seems to be the corrrect place.{quote}
I agree, at least for the most recent releases, since Debian Bullseye's apt
package doesn't deliver this directory. That's why we've been using
{{/usr/share/keyrings}}, which might be reconsidered when upgrading to Bookworm.
was (Author: rtib):
{quote}Keys in /etc/apt/keyrings are not trusted globally. This is in contrast
to the keys in /etc/apt/trusted.gpg.d. I do not know about the ones in
/usr/share/keyring – they might be){quote}
Those in {{/usr/share/keyring}} aren't globally trusted either.
{quote}So /etc/apt/keysrings seems to be the corrrect place.{quote}
I agree, at least for the most recent releases, since Debian Bullseye's apt
package doesn't deliver this directory. That's why we've been using
{{/usr/share/keyrings}}, which might be reconsidered when upgrading to Bookworm.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833147#comment-17833147
]
Tibor Repasi commented on CASSANDRA-19110:
--
{quote}Keys in /etc/apt/keyrings are not trusted globally. This is in contrast
to the keys in /etc/apt/trusted.gpg.d. I do not know about the ones in
/usr/share/keyring – they might be){quote}
Those in {{/usr/share/keyring}} aren't globally trusted either.
{quote}So /etc/apt/keysrings seems to be the corrrect place.{quote}
I agree, at least for the most recent releases, since Debian Bullseye's apt
package doesn't deliver this directory. That's why we've been using
{{/usr/share/keyrings}}, which might be reconsidered when upgrading to Bookworm.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833133#comment-17833133
]
Tibor Repasi commented on CASSANDRA-19110:
--
The situation is not really clear, indeed, nevertheless the Debian Wiki page on
[SecureApt|https://wiki.debian.org/SecureApt#How_to_find_and_add_a_key] is also
referring to {{/usr/share/keyrings}}, while also stating that "{_}For other
archives, there is not yet a standard location where you can find the key for a
given apt repository{_}".
What I'm concerned about is, that keys within {{/etc/share/keyrings}} might be
trusted globally for every apt source. I prefer to pin the keyring explicitly
to the apt source.
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831696#comment-17831696
]
Tibor Repasi edited comment on CASSANDRA-19110 at 3/28/24 9:56 AM:
---
I just got focus on this one and have some notes:
# On Debian (checked on buster, bullseye and bookworm) the package
[debian-archive-keyring|https://packages.debian.org/bookworm/debian-archive-keyring]
- installed by default - is placing keyring files under
{{/usr/share/keyrings/}}, thus this directory is available by default.
# Apt is also supporting armored keyring files; thus you can skip the dearmor
step, if the filename is tailed with {{.asc}}.
This is how we deal with Cassandra installations on our Debian hosts:
{code}
curl -o /usr/share/keyrings/apache-cassandra.asc
https://downloads.apache.org/cassandra/KEYS
{code}
{code}
echo "deb [signed-by=/usr/share/keyrings/apache-cassandra.asc]
https://debian.cassandra.apache.org 41x main" >
/etc/apt/sources.d/apache-cassandra.list
{code}
was (Author: rtib):
I just got focus on this one and have some notes:
# On Debian (checked on buster, bullseye and bookworm) the package
[debian-archive-keyring|https://packages.debian.org/bookworm/debian-archive-keyring]
- installed by default - is placing keyring files under
{{/usr/share/keyrings/}}, thus this directory is available by default.
# Apt is also supporting armored keyring files; thus you can skip the dearmor
step, if the filename is tailed with {{.asc}}.
{code}
curl -o /usr/share/keyrings/apache-cassandra.asc
https://downloads.apache.org/cassandra/KEYS
{code}
{code}
echo "deb [signed-by=/usr/share/keyrings/apache-cassandra.asc]
https://debian.cassandra.apache.org 41x main" >
/etc/apt/sources.d/apache-cassandra.list
{code}
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19110) apt-key deprecation, replace with gpg --dearmor in the docs.
[
https://issues.apache.org/jira/browse/CASSANDRA-19110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831696#comment-17831696
]
Tibor Repasi commented on CASSANDRA-19110:
--
I just got focus on this one and have some notes:
# On Debian (checked on buster, bullseye and bookworm) the package
[debian-archive-keyring|https://packages.debian.org/bookworm/debian-archive-keyring]
- installed by default - is placing keyring files under
{{/usr/share/keyrings/}}, thus this directory is available by default.
# Apt is also supporting armored keyring files; thus you can skip the dearmor
step, if the filename is tailed with {{.asc}}.
{code}
curl -o /usr/share/keyrings/apache-cassandra.asc
https://downloads.apache.org/cassandra/KEYS
{code}
{code}
echo "deb [signed-by=/usr/share/keyrings/apache-cassandra.asc]
https://debian.cassandra.apache.org 41x main" >
/etc/apt/sources.d/apache-cassandra.list
{code}
> apt-key deprecation, replace with gpg --dearmor in the docs.
>
>
> Key: CASSANDRA-19110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19110
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Simon K
>Assignee: Simon K
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> the command `apt-key` is deprecated and soon to be removed, especially on
> Ubuntu.
> the directory `/usr/share/keyrings` for shared keys are also being removed.
> I suggest to convert the docs from
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
> to a simpler command:
> {code:java}
> curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o
> /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
> The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it
> does on 22.04.
> I also suggest to add the source.list.d text from
> {code:java}
> $ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb https://debian.cassandra.apache.org 42x main{code}
> to
> {code:java}
> $ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main" | sudo tee -a
> /etc/apt/sources.list.d/cassandra.sources.list
> deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg]
> https://debian.cassandra.apache.org 42x main {code}
> I have made a [PR|https://github.com/apache/cassandra/pull/2936]
> I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and
> it works just fine.
--
This message was sent by Atlassian Jira
(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-19196) Don't allow to enable direct i/o with broken kernels
[
https://issues.apache.org/jira/browse/CASSANDRA-19196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795906#comment-17795906
]
Tibor Repasi commented on CASSANDRA-19196:
--
{quote}The bug report is perfectly clear to me - 6.1.64 and 6.1.65 kernels have
a bug{quote}
Note that those are vanilla kernel versions. Many Linux distributions patch
their kernels and (back-)port patches across everything. Thus, matching the
version doesn't necessarily mean that the kernel is buggy.
Analog to that, there is a startup-warning if swap is enabled, even if
vm.swappines is turned down. The argument, however, that this could lead to
data corruption weights higher.
In my opinion, as a Cassandra operator, this constellation is easy to oversee
and threatens operations with data loss - possibly all over a cluster, making
this a business risk. Thus, a startup-stopper which can be cleared with a
property seems fine to me.
> Don't allow to enable direct i/o with broken kernels
>
>
> Key: CASSANDRA-19196
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19196
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
>
> https://lwn.net/Articles/954285/, found by [~rustyrazorblade]
--
This message was sent by Atlassian Jira
(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-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761971#comment-17761971
]
Tibor Repasi commented on CASSANDRA-18778:
--
Hi, thanks for pinging. Sorry for the delayed response, I'm just back from
holidays.
I've just tested 5.0-alpha1 (take3) on my test cluster set up with
PEMBasedSslContextFactory which has required CASSANDRA-18124. The patch seems
not inflicting with the features used there.
LGTM
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707509#comment-17707509 ] Tibor Repasi commented on CASSANDRA-18124: -- LGTM, thank you. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704487#comment-17704487 ] Tibor Repasi commented on CASSANDRA-18124: -- My opinion concerning the warnings is, that your approach of changing the warning logic is fine and the only suitable way for 4.1.x. In 5.x however, the legacy configuration parameter should be removed, along with the whole code to generate these warnings. But that's a different issue and I don't know about a ticket for that. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[
https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703974#comment-17703974
]
Tibor Repasi commented on CASSANDRA-18124:
--
One minor issue: nodetool is complaining about configuration
{code}
% bin/nodetool stopdaemon
WARN 08:50:50,063 Only 20,213GiB free across all data volumes. Consider adding
more capacity to your cluster or removing obsolete snapshots
WARN 08:50:50,566 'keystore_password' and 'key_password' both are configured
but since the values match it's okay. Ideally you should only specify one of
them.
WARN 08:50:50,567 'keystore_password' and 'key_password' both are configured
but since the values match it's okay. Ideally you should only specify one of
them.
Cassandra has shutdown.
{code}
> Config parameter keystore_password should be nullable
> -
>
> Key: CASSANDRA-18124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18124
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tibor Repasi
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Some SSL configuration may pass unencrypted private keys. PEMReader might
> accept that by assuming keyPassword to be null in that case (e.g.
> https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103).
> Current configuration reader does not accept keystore_password parameter to
> be set null or empty in the cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703956#comment-17703956 ] Tibor Repasi commented on CASSANDRA-18124: -- I've tested it, looks good. I haven't tested with intermediate CA certificates for now, but that wasn't the issue either. One small suggestion: currently the configuration example can only be found on the website, would you mind to put configuration examples using PEMBasedSslContextFactory into the comments of cassandra.yaml? That would lower the setup threshold. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703578#comment-17703578 ] Tibor Repasi commented on CASSANDRA-18124: -- Sorry for the delay, I was busy the last few days. Of course, I'll have a look and test it. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18326) Debian package repository misconfiguration
[
https://issues.apache.org/jira/browse/CASSANDRA-18326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700139#comment-17700139
]
Tibor Repasi commented on CASSANDRA-18326:
--
Hi [~brandon.williams] , it looks good to me. Apt update took it and recent
version is available now.
> Debian package repository misconfiguration
> --
>
> Key: CASSANDRA-18326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18326
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Tibor Repasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: NA
>
>
> Debian apt is failing on current jfrog repository access for 40x releases
> with:
> {code}
> W: Conflicting distribution: https://debian.cassandra.apache.org 40x
> InRelease (expected 40x but got 40)
> E: Repository 'https://debian.cassandra.apache.org 40x InRelease' changed its
> 'Codename' value from '40x' to '40'
> N: This must be accepted explicitly before updates for this repository can be
> applied. See apt-secure(8) manpage for details.
> {code}
> This is caused by the typo in
> [dists/40x/Release|https://debian.cassandra.apache.org/dists/40x/Release]
> containing
> {code}
> Codename: 40
> {code}
> but it is expected to be
> {code}
> Codename: 40x
> {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] [Created] (CASSANDRA-18326) Debian package repository misconfiguration
Tibor Repasi created CASSANDRA-18326:
Summary: Debian package repository misconfiguration
Key: CASSANDRA-18326
URL: https://issues.apache.org/jira/browse/CASSANDRA-18326
Project: Cassandra
Issue Type: Bug
Components: Packaging
Reporter: Tibor Repasi
Debian apt is failing on current jfrog repository access for 40x releases with:
{code}
W: Conflicting distribution: https://debian.cassandra.apache.org 40x InRelease
(expected 40x but got 40)
E: Repository 'https://debian.cassandra.apache.org 40x InRelease' changed its
'Codename' value from '40x' to '40'
N: This must be accepted explicitly before updates for this repository can be
applied. See apt-secure(8) manpage for details.
{code}
This is caused by the typo in
[dists/40x/Release|https://debian.cassandra.apache.org/dists/40x/Release]
containing
{code}
Codename: 40
{code}
but it is expected to be
{code}
Codename: 40x
{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-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=17698748#comment-17698748 ] Tibor Repasi commented on CASSANDRA-18303: -- No worries. Thank you! > 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.1, 5.0 > > > 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-18307) Release 4.0.8 not available on jfrog package repositories
[ https://issues.apache.org/jira/browse/CASSANDRA-18307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698195#comment-17698195 ] Tibor Repasi commented on CASSANDRA-18307: -- Yes, 4.0.8 is now available in the repository. Thank you, [~brandon.williams]. > Release 4.0.8 not available on jfrog package repositories > - > > Key: CASSANDRA-18307 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18307 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Tibor Repasi >Assignee: Brandon Williams >Priority: Normal > > Release 4.0.8 was published to dist/downloads.a.o only and seems not > available at apache.jfrog.io neither for Debian nor RPM. -- This message was sent by Atlassian Jira (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-18307) Release 4.0.8 not available on jfrog package repositories
[ https://issues.apache.org/jira/browse/CASSANDRA-18307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-18307: - Component/s: Packaging > Release 4.0.8 not available on jfrog package repositories > - > > Key: CASSANDRA-18307 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18307 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Tibor Repasi >Priority: Normal > > Release 4.0.8 was published to dist/downloads.a.o only and seems not > available at apache.jfrog.io neither for Debian nor RPM. -- This message was sent by Atlassian Jira (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-18307) Release 4.0.8 not available on jfrog package repositories
Tibor Repasi created CASSANDRA-18307: Summary: Release 4.0.8 not available on jfrog package repositories Key: CASSANDRA-18307 URL: https://issues.apache.org/jira/browse/CASSANDRA-18307 Project: Cassandra Issue Type: Bug Reporter: Tibor Repasi Release 4.0.8 was published to dist/downloads.a.o only and seems not available at apache.jfrog.io neither for Debian nor RPM. -- This message was sent by Atlassian Jira (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=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-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=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] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[
https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649180#comment-17649180
]
Tibor Repasi commented on CASSANDRA-18124:
--
The use and default value of {{truststore_password}} should also be reviewed in
order to avoid startup warnings like:
{code}
PEMBasedSslContextFactory.java:125 - PEM based truststore should not be using
password. Ignoring the given value in 'truststore_password' configuration.
{code}
> Config parameter keystore_password should be nullable
> -
>
> Key: CASSANDRA-18124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18124
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Priority: Normal
>
> Some SSL configuration may pass unencrypted private keys. PEMReader might
> accept that by assuming keyPassword to be null in that case (e.g.
> https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103).
> Current configuration reader does not accept keystore_password parameter to
> be set null or empty in the cassandra.yaml.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-18124: - Description: Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). Current configuration reader does not accept keystore_password parameter to be set null or empty in the cassandra.yaml. was:Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug >Reporter: Tibor Repasi >Priority: Normal > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18124) Config parameter keystore_password should be nullable
Tibor Repasi created CASSANDRA-18124: Summary: Config parameter keystore_password should be nullable Key: CASSANDRA-18124 URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 Project: Cassandra Issue Type: Bug Reporter: Tibor Repasi Some SSL configuration may pass unencrypted private keys. PEMReader might accept that by assuming keyPassword to be null in that case (e.g. https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). -- This message was sent by Atlassian Jira (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-18117) Blog article contains outdated parameter setting
[ https://issues.apache.org/jira/browse/CASSANDRA-18117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-18117: - Summary: Blog article contains outdated parameter setting (was: Blog article contains outdated parameter settings) > Blog article contains outdated parameter setting > > > Key: CASSANDRA-18117 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18117 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Tibor Repasi >Priority: Normal > Labels: pull-request-available > > The parameter as described in the blog article on new SSTable identifier has > been changed since the article. -- This message was sent by Atlassian Jira (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-18117) Blog article contains outdated parameter
[ https://issues.apache.org/jira/browse/CASSANDRA-18117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-18117: - Summary: Blog article contains outdated parameter (was: Blog article contains outdated parameter setting) > Blog article contains outdated parameter > > > Key: CASSANDRA-18117 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18117 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Blog >Reporter: Tibor Repasi >Priority: Normal > Labels: pull-request-available > > The parameter as described in the blog article on new SSTable identifier has > been changed since the article. -- This message was sent by Atlassian Jira (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-18117) Blog article contains outdated parameter settings
Tibor Repasi created CASSANDRA-18117: Summary: Blog article contains outdated parameter settings Key: CASSANDRA-18117 URL: https://issues.apache.org/jira/browse/CASSANDRA-18117 Project: Cassandra Issue Type: Bug Components: Documentation/Blog Reporter: Tibor Repasi The parameter as described in the blog article on new SSTable identifier has been changed since the article. -- This message was sent by Atlassian Jira (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-18082) Broken link in the documentation
Tibor Repasi created CASSANDRA-18082: Summary: Broken link in the documentation Key: CASSANDRA-18082 URL: https://issues.apache.org/jira/browse/CASSANDRA-18082 Project: Cassandra Issue Type: Bug Components: Documentation/Website Reporter: Tibor Repasi 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-17654) Restore replica count sessions may get stalled
[ https://issues.apache.org/jira/browse/CASSANDRA-17654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-17654: - Since Version: 3.11.13 > Restore replica count sessions may get stalled > -- > > Key: CASSANDRA-17654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17654 > Project: Cassandra > Issue Type: Bug >Reporter: Tibor Repasi >Priority: Normal > > I’ve observated, that Restore replica count sessions seem not always removed > properly after all streams has finished and stuck there for the rest of the > lifetime of the node. There is no streaming ongoing, no pending tasks in > tpstats no compactions backlog, even scheduled repairs are running fine. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17654) Restore replica count sessions may get stalled
[ https://issues.apache.org/jira/browse/CASSANDRA-17654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Repasi updated CASSANDRA-17654: - Impacts: (was: None) > Restore replica count sessions may get stalled > -- > > Key: CASSANDRA-17654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17654 > Project: Cassandra > Issue Type: Bug >Reporter: Tibor Repasi >Priority: Normal > > I’ve observated, that Restore replica count sessions seem not always removed > properly after all streams has finished and stuck there for the rest of the > lifetime of the node. There is no streaming ongoing, no pending tasks in > tpstats no compactions backlog, even scheduled repairs are running fine. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17654) Restore replica count sessions may get stalled
Tibor Repasi created CASSANDRA-17654: Summary: Restore replica count sessions may get stalled Key: CASSANDRA-17654 URL: https://issues.apache.org/jira/browse/CASSANDRA-17654 Project: Cassandra Issue Type: Bug Reporter: Tibor Repasi I’ve observated, that Restore replica count sessions seem not always removed properly after all streams has finished and stuck there for the rest of the lifetime of the node. There is no streaming ongoing, no pending tasks in tpstats no compactions backlog, even scheduled repairs are running fine. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Implement nodetool command to list data directories of existing tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526413#comment-17526413
]
Tibor Repasi commented on CASSANDRA-17568:
--
Thank you for the commitment, the reviews and the productive feedback. Glad to
see that coming in 4.1.
> Implement nodetool command to list data directories of existing tables
> --
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10h
> Remaining Estimate: 0h
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Implement nodetool command to list data directories of existing tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525998#comment-17525998
]
Tibor Repasi commented on CASSANDRA-17568:
--
Thanks [~brandon.williams]. I've reverted it. I'm afraid, that current state is
how far this improvement can go for now.
> Implement nodetool command to list data directories of existing tables
> --
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 9h 10m
> Remaining Estimate: 0h
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Implement nodetool command to list data directories of existing tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525975#comment-17525975
]
Tibor Repasi commented on CASSANDRA-17568:
--
With this
[commit|https://github.com/apache/cassandra/pull/1580/commits/a759f9cb65bbd0a4620bcc7c6442a14e41507dd8]
I've added a raw implementation of an {{--list-orphans}} option which is
traversing all {{data_file_directories}} recursively in a depth of 2 and
listing all paths which are not known to be used for tables.
However, it does correctly list empty keyspace directories and dropped tables,
I have some objections:
# there is a {{system/_paxos_repair_state}} directory (I'm not familiar with)
which is always listed; probably we would need a static exclude list
# nodetool is a tool which is intended to interact with a Cassandra process via
JMX, this feature is interacting primarily with the filesystem
Therefore I don't really like this feature, it feels wrong, I would not unhappy
to revert it.
> Implement nodetool command to list data directories of existing tables
> --
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Implement nodetool command to list data directories of existing tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525749#comment-17525749
]
Tibor Repasi commented on CASSANDRA-17568:
--
I've addressed all review comments for now and looking forward to add an option
listing the orphaned directories.
> Implement nodetool command to list data directories of existing tables
> --
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525440#comment-17525440
]
Tibor Repasi edited comment on CASSANDRA-17568 at 4/21/22 6:37 AM:
---
Hi, thanks for the feedback.
{quote}
1) return all data directories of a particular table(s).
2) return all data directories which are eligible to be deleted as the
respective keyspace / table (or both) does not exist anymore in Cassandra.
You implemented 1) but I miss 2).
{quote}
That's right. But, it is not trivial to identify directories of deleted tables
and keyspaces, since Cassandra doesn't keep track of them. Deleting directories
which aren't data paths of any existing table would assume that nothing else
could have created them, which makes this approach particularly dangerous.
The main goal might obviously be to clean up directories Cassandra created and
not using anymore. I like CASSANDRA-16843 and I really love CASSANDRA-16451,
which both improve control and handling of snapshots. I could imagine Cassandra
to keep track of directories belonging to dropped tables and keyspaces and
clean them up automatically under specific circumstances after some time. Maybe
data directories could have bounded TTL? But, I think that's a complete
different discussion track. This ticket and my patch are about making things
visible to support operators.
BTW, I am aware about the deadline for the version cut.
was (Author: rtib):
Hi, thanks for the feedback.
{quote}
1) return all data directories of a particular table(s).
2) return all data directories which are eligible to be deleted as the
respective keyspace / table (or both) does not exist anymore in Cassandra.
You implemented 1) but I miss 2).
{quote}
That's right. But, it is not trivial to identify directories of deleted tables
and keyspaces, since Cassandra doesn't keep track of them. Deleting directories
which aren't data paths of any existing table would assume that nothing else
could have created them, which makes this approach particularly dangerous.
The main goal might obviously be to clean up directories Cassandra created and
not using anymore. I like CASSANDRA-16843 and I really love CASSANDRA-16451,
which both improve control and handling of snapshots. I could imagine Cassandra
to keep track of directories belonging to dropped tables and keyspaces and
clean them up automatically after some time. Maybe data directories could have
bounded TTL? But, I think that's a complete different discussion track. This
ticket and my patch are about making things visible to support operators.
BTW, I am aware about the deadline for the version cut.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525440#comment-17525440
]
Tibor Repasi edited comment on CASSANDRA-17568 at 4/21/22 6:36 AM:
---
Hi, thanks for the feedback.
{quote}
1) return all data directories of a particular table(s).
2) return all data directories which are eligible to be deleted as the
respective keyspace / table (or both) does not exist anymore in Cassandra.
You implemented 1) but I miss 2).
{quote}
That's right. But, it is not trivial to identify directories of deleted tables
and keyspaces, since Cassandra doesn't keep track of them. Deleting directories
which aren't data paths of any existing table would assume that nothing else
could have created them, which makes this approach particularly dangerous.
The main goal might obviously be to clean up directories Cassandra created and
not using anymore. I like CASSANDRA-16843 and I really love CASSANDRA-16451,
which both improve control and handling of snapshots. I could imagine Cassandra
to keep track of directories belonging to dropped tables and keyspaces and
clean them up automatically after some time. Maybe data directories could have
bounded TTL? But, I think that's a complete different discussion track. This
ticket and my patch are about making things visible to support operators.
BTW, I am aware about the deadline for the version cut.
was (Author: rtib):
Hi, thanks for the feedback.
{quote}
1) return all data directories of a particular table(s).
2) return all data directories which are eligible to be deleted as the
respective keyspace / table (or both) does not exist anymore in Cassandra.
You implemented 1) but I miss 2).
{quote}
That's right. But, it is not trivial to identify directories of deleted tables
and keyspaces, since Cassandra doesn't keep track of them. Deleting directories
which aren't data paths of any existing table would assume that nothing else
could have created them, which makes this approach particularly dangerous.
The main goal might obviously be to clean up directories Cassandra created and
not using anymore. I like CASSANDRA-16843 and I really love CASSANDRA-16451,
which both improve control and handling of snapshots. I could imagine Cassandra
to keep track of directories belonging to tables and keyspaces even after they
have been dropped and clean them up automatically after some time. Maybe data
directories could have bounded TTL? But, I think that's a complete different
discussion track. This ticket and my patch are about making things visible to
support operators.
BTW, I am aware about the deadline for the version cut.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525440#comment-17525440
]
Tibor Repasi commented on CASSANDRA-17568:
--
Hi, thanks for the feedback.
{quote}
1) return all data directories of a particular table(s).
2) return all data directories which are eligible to be deleted as the
respective keyspace / table (or both) does not exist anymore in Cassandra.
You implemented 1) but I miss 2).
{quote}
That's right. But, it is not trivial to identify directories of deleted tables
and keyspaces, since Cassandra doesn't keep track of them. Deleting directories
which aren't data paths of any existing table would assume that nothing else
could have created them, which makes this approach particularly dangerous.
The main goal might obviously be to clean up directories Cassandra created and
not using anymore. I like CASSANDRA-16843 and I really love CASSANDRA-16451,
which both improve control and handling of snapshots. I could imagine Cassandra
to keep track of directories belonging to tables and keyspaces even after they
have been dropped and clean them up automatically after some time. Maybe data
directories could have bounded TTL? But, I think that's a complete different
discussion track. This ticket and my patch are about making things visible to
support operators.
BTW, I am aware about the deadline for the version cut.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Fix For: 4.x
>
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17568) Tool to list data directories
[
https://issues.apache.org/jira/browse/CASSANDRA-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525262#comment-17525262
]
Tibor Repasi commented on CASSANDRA-17568:
--
GitHub [PR#1580|https://github.com/apache/cassandra/pull/1580] is open with
request for comments.
> Tool to list data directories
> -
>
> Key: CASSANDRA-17568
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Tibor Repasi
>Priority: Normal
>
> When a table is created, dropped and re-created with the same name,
> directories remain within data paths. Operators may be challenged finding out
> which directories belong to existing tables and which may be subject to
> removal. However, the information is available in CQL as well as in MBeans
> via JMX, a convenient access to this information is still missing.
> My proposal is a new nodetool subcommand allowing to list data paths of all
> existing tables.
> {code}
> % bin/nodetool datapaths -- example
> Keyspace : example
> Table : test
> Paths :
>
> /var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17568) Tool to list data directories
Tibor Repasi created CASSANDRA-17568:
Summary: Tool to list data directories
Key: CASSANDRA-17568
URL: https://issues.apache.org/jira/browse/CASSANDRA-17568
Project: Cassandra
Issue Type: New Feature
Components: Tool/nodetool
Reporter: Tibor Repasi
When a table is created, dropped and re-created with the same name, directories
remain within data paths. Operators may be challenged finding out which
directories belong to existing tables and which may be subject to removal.
However, the information is available in CQL as well as in MBeans via JMX, a
convenient access to this information is still missing.
My proposal is a new nodetool subcommand allowing to list data paths of all
existing tables.
{code}
% bin/nodetool datapaths -- example
Keyspace : example
Table : test
Paths :
/var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17502) Security enforcement by enabling "two-person concept" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Description:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-person
concept" (a.k.a. two-man rule, four-eyes principle) grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - r_patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE r_patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
CREATE ROLE r_security_admin;
GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
GRANT r_security_admin TO security_admin_1;
GRANT r_security_admin TO security_admin_2;
GRANT r_security_admin TO security_admin_3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT r_patientdata_access TO doctor_house;
{code}
must be conducted by at least two different security admins of the available
ones above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
was:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-person
concept" (a.k.a. two-man rule, four-eyes principle) grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE r_patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
CREATE ROLE r_security_admin;
GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
GRANT r_security_admin TO security_admin_1;
GRANT r_security_admin TO security_admin_2;
GRANT r_security_admin TO security_admin_3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT r_patientdata_access TO doctor_house;
{code}
must be conducted by at least two different security admins of the available
ones above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
> Security enforcement by enabling "two-person concept" authorization
> ---
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce
> "two-person concept" (a.k.a. two-man rule, four-eyes principle) grant of
> roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.{quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - r_patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE r_patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO
[jira] [Updated] (CASSANDRA-17502) Security enforcement by enabling "two-person concept" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Description:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-person
concept" (a.k.a. two-man rule, four-eyes principle) grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE r_patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
CREATE ROLE r_security_admin;
GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
GRANT r_security_admin TO security_admin_1;
GRANT r_security_admin TO security_admin_2;
GRANT r_security_admin TO security_admin_3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT r_patientdata_access TO doctor_house;
{code}
must be conducted by at least two different security admins of the available
ones above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
was:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-person
concept" (a.k.a. two-man rule) grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE r_patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
CREATE ROLE r_security_admin;
GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
GRANT r_security_admin TO security_admin_1;
GRANT r_security_admin TO security_admin_2;
GRANT r_security_admin TO security_admin_3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT r_patientdata_access TO doctor_house;
{code}
must be conducted by at least two different security admins of the available
ones above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
> Security enforcement by enabling "two-person concept" authorization
> ---
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce
> "two-person concept" (a.k.a. two-man rule, four-eyes principle) grant of
> roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.{quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE r_patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
> CREATE ROLE
[jira] [Commented] (CASSANDRA-17502) Security enforcement by enabling "two-person concept" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515092#comment-17515092
]
Tibor Repasi commented on CASSANDRA-17502:
--
Sure, and I agree with that as well. However, the concept is widely known as
the "two-man rule," sometimes referred to as the "two-person concept", which
sounds more appropriate. Along with the other suggestions, I have changed the
wording, except for the quote.
> Security enforcement by enabling "two-person concept" authorization
> ---
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce
> "two-person concept" (a.k.a. two-man rule) grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.{quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE r_patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
> CREATE ROLE r_security_admin;
> GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
> GRANT r_security_admin TO security_admin_1;
> GRANT r_security_admin TO security_admin_2;
> GRANT r_security_admin TO security_admin_3;
> {code}
> Security admins are allowed to grant the role, but it would need at least two
> of them (as defined by GRANTORS) to do so to allow the user to actually
> access the data.
> Thus,
> {code}
> GRANT r_patientdata_access TO doctor_house;
> {code}
> must be conducted by at least two different security admins of the available
> ones above.
> When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
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-17502) Security enforcement by enabling "two-person concept" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Description:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-person
concept" (a.k.a. two-man rule) grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE r_patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
CREATE ROLE r_security_admin;
GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
GRANT r_security_admin TO security_admin_1;
GRANT r_security_admin TO security_admin_2;
GRANT r_security_admin TO security_admin_3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT r_patientdata_access TO doctor_house;
{code}
must be conducted by at least two different security admins of the available
ones above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
was:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two different admin_guys of the available ones
above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
> Security enforcement by enabling "two-person concept" authorization
> ---
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce
> "two-person concept" (a.k.a. two-man rule) grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.{quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE r_patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO r_patientdata_access;
> CREATE ROLE r_security_admin;
> GRANT AUTHORIZE r_patientdata_access TO r_security_admin;
> GRANT r_security_admin TO
[jira] [Updated] (CASSANDRA-17502) Security enforcement by enabling "two-person concept" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Summary: Security enforcement by enabling "two-person concept"
authorization (was: Security enforcement by enabling "two-man rule"
authorization)
> Security enforcement by enabling "two-person concept" authorization
> ---
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce "two-man
> rule" grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.
> {quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
> CREATE ROLE security_admin;
> GRANT AUTHORIZE patientdata_access TO security_admin;
> GRANT security_admin TO admin_guy1;
> GRANT security_admin TO admin_guy2;
> GRANT security_admin TO admin_guy3;
> {code}
> Security admins are allowed to grant the role, but it would need at least two
> of them (as defined by GRANTORS) to do so to allow the user to actually
> access the data.
> Thus,
> {code}
> GRANT patientdata_access TO doctor_house;
> {code}
> must be conducted by at least two different admin_guys of the available ones
> above.
> When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
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-17502) Security enforcement by enabling "two-man rule" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Description:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two different admin_guys of the available ones
above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
was:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two of the three admin_guys above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
> Security enforcement by enabling "two-man rule" authorization
> -
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce "two-man
> rule" grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.
> {quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
> CREATE ROLE security_admin;
> GRANT AUTHORIZE patientdata_access TO security_admin;
> GRANT security_admin TO admin_guy1;
> GRANT security_admin TO admin_guy2;
> GRANT security_admin TO admin_guy3;
> {code}
> Security admins are allowed to grant the
[jira] [Created] (CASSANDRA-17502) Security enforcement by enabling "two-man rule" authorization
Tibor Repasi created CASSANDRA-17502:
Summary: Security enforcement by enabling "two-man rule"
authorization
Key: CASSANDRA-17502
URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
Project: Cassandra
Issue Type: New Feature
Reporter: Tibor Repasi
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two of the three admin_guys above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
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-17445) Library airlift/airline has been deprecated
[ https://issues.apache.org/jira/browse/CASSANDRA-17445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507582#comment-17507582 ] Tibor Repasi commented on CASSANDRA-17445: -- As a good starting point, both are licensed under Apache 2.0. I am looking into it trying to prototype upgrades to both. At first sight, picocli seems to be more modern and provide more features, while airline 2 is a direct fork of airlift/airline, the upgrade, however, isn't that straightforward as the name suggests. Also, we should be open for other alternatives. But, there might be some considerations here to be cleared at first: * We could choose a replacement by looking at the implementation effort only. That would ideally be just a drop-in, nothing more. * We could look at provided features and the need for them, e.g. CASSANDRA-13947 is suggesting to add an examples section, extended help or even a documentation generator; features which might leverage the usability, but increase the effort needed to switch. * From my point of view, the most important thing is to not change the default behaviour of the tools as that might break operations processes built around. We do have a couple of unit tests for these tools but I'm not sure about coverage. > Library airlift/airline has been deprecated > --- > > Key: CASSANDRA-17445 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17445 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Tibor Repasi >Priority: Normal > Fix For: 4.x > > > The [airlift/airline|https://github.com/airlift/airline] library has been > deprecated and is not maintained since [8 Jun > 2021|https://github.com/airlift/airline/commit/ae3d7e103bdc140969bde944d4ba09345d663a61]. > It is used in many tools and some tests of Cassandra which should be > reviewed. > Tools using that library: > * org.apache.cassandra.tools.JMXTool > * org.apache.cassandra.tools.NodeTool > * org.apache.cassandra.stress.Compaction > * org.apache.cassandra.fqltool.FullQueryLogTool > Tests using it: > * org.apache.cassandra.simulator.SimulationRunner > Alternatives (as suggested in the depreciation notice): > * [Airline 2|https://rvesse.github.io/airline/] > * [picocli|https://picocli.info] -- 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] [Created] (CASSANDRA-17445) Library airlift/airline has been deprecated
Tibor Repasi created CASSANDRA-17445: Summary: Library airlift/airline has been deprecated Key: CASSANDRA-17445 URL: https://issues.apache.org/jira/browse/CASSANDRA-17445 Project: Cassandra Issue Type: Task Components: Dependencies Reporter: Tibor Repasi The [airlift/airline|https://github.com/airlift/airline] library has been deprecated and is not maintained since [8 Jun 2021|https://github.com/airlift/airline/commit/ae3d7e103bdc140969bde944d4ba09345d663a61]. It is used in many tools and some tests of Cassandra which should be reviewed. Tools using that library: * org.apache.cassandra.tools.JMXTool * org.apache.cassandra.tools.NodeTool * org.apache.cassandra.stress.Compaction * org.apache.cassandra.fqltool.FullQueryLogTool Tests using it: * org.apache.cassandra.simulator.SimulationRunner Alternatives (as suggested in the depreciation notice): * [Airline 2|https://rvesse.github.io/airline/] * [picocli|https://picocli.info] -- 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] (CASSANDRASC-20) Add systemd service unit configuration
[ https://issues.apache.org/jira/browse/CASSANDRASC-20 ] Tibor Repasi deleted comment on CASSANDRASC-20: - was (Author: rtib): Here's my "elevator pitch": https://gist.github.com/rtib/b07b1b09c5c57ebccef212c9666da770 Some things could be dropped when focusing on Cassandra 4.x, some could probably be moved to a drop-in, on the rest I'd request for comments. > Add systemd service unit configuration > -- > > Key: CASSANDRASC-20 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-20 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Jon Haddad >Priority: Normal > > We should add a systemd configuration to allow for standard start / stop / > restart commands. -- 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] (CASSANDRASC-20) Add systemd service unit configuration
[ https://issues.apache.org/jira/browse/CASSANDRASC-20 ] Tibor Repasi deleted comment on CASSANDRASC-20: - was (Author: rtib): We're running several hundred Cassandra nodes and have replaced the init.d script with our own SystemD unit on deployment. I'd love to contribute. > Add systemd service unit configuration > -- > > Key: CASSANDRASC-20 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-20 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Jon Haddad >Priority: Normal > > We should add a systemd configuration to allow for standard start / stop / > restart commands. -- 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] (CASSANDRASC-20) Add systemd service unit configuration
[ https://issues.apache.org/jira/browse/CASSANDRASC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504932#comment-17504932 ] Tibor Repasi commented on CASSANDRASC-20: - Here's my "elevator pitch": https://gist.github.com/rtib/b07b1b09c5c57ebccef212c9666da770 Some things could be dropped when focusing on Cassandra 4.x, some could probably be moved to a drop-in, on the rest I'd request for comments. > Add systemd service unit configuration > -- > > Key: CASSANDRASC-20 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-20 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Jon Haddad >Priority: Normal > > We should add a systemd configuration to allow for standard start / stop / > restart commands. -- 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] (CASSANDRASC-20) Add systemd service unit configuration
[ https://issues.apache.org/jira/browse/CASSANDRASC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504926#comment-17504926 ] Tibor Repasi commented on CASSANDRASC-20: - We're running several hundred Cassandra nodes and have replaced the init.d script with our own SystemD unit on deployment. I'd love to contribute. > Add systemd service unit configuration > -- > > Key: CASSANDRASC-20 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-20 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Jon Haddad >Priority: Normal > > We should add a systemd configuration to allow for standard start / stop / > restart commands. -- 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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502870#comment-17502870
]
Tibor Repasi commented on CASSANDRA-16378:
--
Thank you all for the support.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Fix For: 4.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499797#comment-17499797
]
Tibor Repasi commented on CASSANDRA-16378:
--
Thank you [~e.dimitrova], I've cherry picked your commit
[be699f|https://github.com/apache/cassandra/commit/ab9fcbaf998fb584ae84d584c298af63fcbe699f]
just partly, to not duplicate the entry in CHANGES.txt. Squashed and rebased
onto trunk.
Doc update ticket is open at CASSANDRA-17344.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16501) CMS is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495534#comment-17495534
]
Tibor Repasi commented on CASSANDRA-16501:
--
Is this just the change of default JVM options or are there any other
considerations?
> CMS is deprecated
> -
>
> Key: CASSANDRA-16501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16501
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> When running under Java 11, you will see:
> {quote}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> {quote}
> Per the JEP: http://openjdk.java.net/jeps/291 " The G1 garbage collector is
> intended, in the long term, to be a replacement for most uses of CMS."
> We don't need to act on this immediately at the time of writing this ticket,
> but it is something that will eventually happen so we should get ahead of it.
--
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-17344) Documentation update of virtual table system_views.clients
[ https://issues.apache.org/jira/browse/CASSANDRA-17344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486375#comment-17486375 ] Tibor Repasi commented on CASSANDRA-17344: -- PR [#1435|https://github.com/apache/cassandra/pull/1435] contains the documentation updates. > Documentation update of virtual table system_views.clients > -- > > Key: CASSANDRA-17344 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 > Project: Cassandra > Issue Type: Improvement > Components: Documentation >Reporter: Tibor Repasi >Assignee: Tibor Repasi >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > With CASSANDRA-16378 there are changes introduced to virtual table > system_views.clients. This is updating the documentation page. -- 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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486376#comment-17486376
]
Tibor Repasi commented on CASSANDRA-16378:
--
CASSANDRA-17344 is open and linked to the according PR.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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] [Created] (CASSANDRA-17344) Documentation update of virtual table system_views.clients
Tibor Repasi created CASSANDRA-17344: Summary: Documentation update of virtual table system_views.clients Key: CASSANDRA-17344 URL: https://issues.apache.org/jira/browse/CASSANDRA-17344 Project: Cassandra Issue Type: Improvement Components: Documentation Reporter: Tibor Repasi Assignee: Tibor Repasi With CASSANDRA-16378 there are changes introduced to virtual table system_views.clients. This is updating the documentation page. -- 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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485138#comment-17485138
]
Tibor Repasi commented on CASSANDRA-16378:
--
At commit
[#e7ad|https://github.com/rtib/cassandra/commit/78a069a331da1b36ef1138a3b3dfc757a1a2e7ad]
I've updated the according documentation page, but I'm afraid that this one
will need further review, as many things have changed since this page was
written and page might be moved as with 4.1 virtual tables won't be new anymore.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484825#comment-17484825
]
Tibor Repasi commented on CASSANDRA-16378:
--
Hi [~blerer] , the PR is ready for review. What's the next step?
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463358#comment-17463358
]
Tibor Repasi commented on CASSANDRA-16378:
--
Finally, nodetool can also expose the options (admittedly, is not very pretty)
{code}
% bin/nodetool clientstats --all
Address SSL CipherProtocol Version User Keyspace
Requests Driver-Name Driver-Version
Client-Options
localhost/127.0.0.1:50576 false undefined undefined 5 anonymous
3DataStax Python Driver 3.25.0
{"DRIVER_VERSION":"3.25.0","DRIVER_NAME":"DataStax Python
Driver","CQL_VERSION":"3.4.5"}
/127.0.0.1:50594 false undefined undefined 5 anonymous
3DataStax Java driver for Apache Cassandra(R) 4.13.0
{"DRIVER_NAME":"DataStax Java driver for Apache
Cassandra(R)","APPLICATION_VERSION":"1.2.3","DRIVER_VERSION":"4.13.0","CLIENT_ID":"e502fa5a-7e63-4c30-b960-7b41870a8bd9","APPLICATION_NAME":"TestApp","CQL_VERSION":"3.0.0"}
localhost/127.0.0.1:50575 false undefined undefined 5 anonymous
16 DataStax Python Driver 3.25.0
{"DRIVER_VERSION":"3.25.0","DRIVER_NAME":"DataStax Python
Driver","CQL_VERSION":"3.4.5"}
/127.0.0.1:50593 false undefined undefined 5 anonymous
18 DataStax Java driver for Apache Cassandra(R) 4.13.0
{"DRIVER_NAME":"DataStax Java driver for Apache
Cassandra(R)","APPLICATION_VERSION":"1.2.3","DRIVER_VERSION":"4.13.0","CLIENT_ID":"e502fa5a-7e63-4c30-b960-7b41870a8bd9","APPLICATION_NAME":"TestApp","CQL_VERSION":"3.0.0"}
Total connected clients: 4
User Connections
anonymous 4
{code}
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463328#comment-17463328
]
Tibor Repasi edited comment on CASSANDRA-16378 at 12/21/21, 4:16 PM:
-
Solved the above. My remaining question on that is, what is MultiCell and why
is it needed to be false?
Have updated the PR. Now, you can query the following:
{code}
superuser@cqlsh> SELECT address, port, client_options FROM system_views.clients;
address | port | client_options
---+---+-
127.0.0.1 | 49172 | {'APPLICATION_NAME': 'TestApp', 'APPLICATION_VERSION':
'1.2.3', 'CLIENT_ID': '79572fc6-8a05-419d-b53a-073d03d601e7', 'CQL_VERSION':
'3.0.0', 'DRIVER_NAME': 'DataStax Java driver for Apache Cassandra(R)',
'DRIVER_VERSION': '4.13.0'}
127.0.0.1 | 49173 | {'APPLICATION_NAME': 'TestApp', 'APPLICATION_VERSION':
'1.2.3', 'CLIENT_ID': '79572fc6-8a05-419d-b53a-073d03d601e7', 'CQL_VERSION':
'3.0.0', 'DRIVER_NAME': 'DataStax Java driver for Apache Cassandra(R)',
'DRIVER_VERSION': '4.13.0'}
127.0.0.1 | 64951 |
{'CQL_VERSION': '3.4.5', 'DRIVER_NAME': 'DataStax Python Driver',
'DRIVER_VERSION': '3.25.0'}
127.0.0.1 | 64953 |
{'CQL_VERSION': '3.4.5', 'DRIVER_NAME': 'DataStax Python Driver',
'DRIVER_VERSION': '3.25.0'}
(4 rows)
{code}
was (Author: rtib):
Solved the above. My remaining question on that is, what is MultiCell and why
is it needed to be false?
Have updated the PR. Now, you can query the following:
{code}
superuser@cqlsh> SELECT address, port, client_options FROM system_views.clients;
address | port | client_options
---+---+---
127.0.0.1 | 64951 | {'CQL_VERSION': '3.4.5', 'DRIVER_NAME': 'DataStax Python
Driver', 'DRIVER_VERSION': '3.25.0'}
127.0.0.1 | 64953 | {'CQL_VERSION': '3.4.5', 'DRIVER_NAME': 'DataStax Python
Driver', 'DRIVER_VERSION': '3.25.0'}
(2 rows)
{code}
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463322#comment-17463322
]
Tibor Repasi commented on CASSANDRA-16378:
--
Help needed. I didn't found any example to add a collection type to a virtual
table.
My approach to add a column of CQL type {{map}} to the clients table
is like:
{code:java}
ClientsTable(String keyspace)
{
super(TableMetadata.builder(keyspace, "clients")
...
.addRegularColumn(CLIENT_OPTIONS,
MapType.getInstance(UTF8Type.instance, UTF8Type.instance, true))
...
{code}
filling it with data:
{code:java}
public DataSet data()
...
result.row(remoteAddress.getAddress(), remoteAddress.getPort())
...
.column(CLIENT_OPTIONS, client.clientOptions())
{code}
where ConnectedClient#clientOptions() is returning a {{Map}}.
Unfortunately, querying that column ends up with
{code:java}
ERROR [Native-Transport-Requests-1] 2021-12-21 16:26:29,828
ExceptionHandlers.java:230 - Unexpected exception during request; channel =
[id: 0x13828495, L:/127.0.0.1:9042 - R:localhost/127.0.0.1:64184]
java.lang.AssertionError: Column system_views.clients(client_options:
org.apache.cassandra.db.marshal.MapType(org.apache.cassandra.db.marshal.UTF8Type,org.apache.cassandra.db.marshal.UTF8Type))
isComplex: true with cellpath: null
at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:48)
at org.apache.cassandra.db.rows.BufferCell.live(BufferCell.java:63)
at org.apache.cassandra.db.rows.BufferCell.live(BufferCell.java:58)
at
org.apache.cassandra.db.virtual.SimpleDataSet$Row.lambda$toTableRow$0(SimpleDataSet.java:193)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at
org.apache.cassandra.db.virtual.SimpleDataSet$Row.toTableRow(SimpleDataSet.java:189)
at
org.apache.cassandra.db.virtual.SimpleDataSet$SimplePartition$1.computeNext(SimpleDataSet.java:155)
at
org.apache.cassandra.db.virtual.SimpleDataSet$SimplePartition$1.computeNext(SimpleDataSet.java:148)
{code}
What is issue I can't see?
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460437#comment-17460437
]
Tibor Repasi commented on CASSANDRA-16378:
--
As a reasonable alternative, we could capture all options from STARTUP MESSAGE
into a hash and output that via the clients virtual table as a collection. That
could be more versatile but add more complexity. That would also need to
clarify of transporting all options or just those not consumed otherwise.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460113#comment-17460113
]
Tibor Repasi commented on CASSANDRA-16378:
--
As I understood the
[native_protocol_v5.spec|https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec],
the list of options is already arbitrary, which is comparable to HTTP
X-Headers. StartupMessage is a codec that decodes the payload to get all the
supported options.
DataStax has extended the java-driver to send application_name and
application_version options along. Somewhere I've seen that SpringBoot
automatically fills in these properties, thus they are available, but not yet
appreciated by Apache Cassandra.
When the applications connecting to the Cassandra clusters I run started to
move from named on-prem hosts to Kubernetes, I was wondering how do I find out
which applications are connecting now, as the far side tcp endpoints moved to
some arbitrary worker nodes which may run other applications as well.
So the main objective from the operators point of view is to improve visibility
by exposing what's already provided.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459440#comment-17459440
]
Tibor Repasi edited comment on CASSANDRA-16378 at 12/15/21, 8:11 AM:
-
The additional information has lowered the threshold to attack my first
contribution to Cassandra.
I've added most of the necessary things as described without breaking any unit
tests so far. Linked the PR.
Got stuck with the unit test, which I'd appreciate some hints how I can inject
driver attributes, application_name and application_version, into the session
to assert the contents of the virtual table.
Still a question if nodetool would need change to expose the data on the
command line.
was (Author: rtib):
The additional information has lowered the threshold to attack my first
contribution to Cassandra.
I've added most of the necessary things as described without breaking any unit
tests so far. Linked the PR.
Got stuck with the unit test, which I'd appreciate some hints how I can inject
driver attributes into the session to assert the contents of the virtual table.
Still a question if nodetool would need change to expose the data on the
command line.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459440#comment-17459440
]
Tibor Repasi commented on CASSANDRA-16378:
--
The additional information has lowered the threshold to attack my first
contribution to Cassandra.
I've added most of the necessary things as described without breaking any unit
tests so far. Linked the PR.
Got stuck with the unit test, which I'd appreciate some hints how I can inject
driver attributes into the session to assert the contents of the virtual table.
Still a question if nodetool would need change to expose the data on the
command line.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi reassigned CASSANDRA-16378:
Assignee: Tibor Repasi
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-16378:
-
Description:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful to exposed this information via virtual table
{{system_views.clients}} and with {{nodetool clientstats}}.
was:
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful if this information is exposed via virtual table
{{system_views.clients}} as well as with {{nodetool clientstats}}.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Priority: Normal
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table
> {{system_views.clients}} and with {{nodetool clientstats}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients
Tibor Repasi created CASSANDRA-16378:
Summary: Expose application_name and application_version in
virtual table system_views.clients
Key: CASSANDRA-16378
URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
Project: Cassandra
Issue Type: Improvement
Components: Feature/Virtual Tables
Reporter: Tibor Repasi
Recent java-driver's
[com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
respects properties
[ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
and
[ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
It would be helpful if this information is exposed via virtual table
{{system_views.clients}} as well as with {{nodetool clientstats}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238560#comment-17238560
]
Tibor Repasi commented on CASSANDRA-16259:
--
No, redistributing index summaries does not affect the current issue. Get well
soon.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta
>
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
>
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17233382#comment-17233382
]
Tibor Repasi commented on CASSANDRA-16259:
--
Not in general. First, the bug is hitting only tables having both old and new
SSTables, so it may happen, that a table having old SSTables only will work
until it eventually get a new SSTable. Thus, finding out which tables are
affected now, doesn't mean that in the future no more tables could suffer from
this bug. Second, be aware of the fact that scrubbing a table using LCS will
reset all SSTables to L0, which may have performance implications. Third, you
would need to scrub all nodes, which could lead to data loss, therefore a full
repair after the scrub is advisable on the node before scrubbing the next node.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta
>
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231238#comment-17231238
]
Tibor Repasi commented on CASSANDRA-16259:
--
Well, that would explain why scrubbing the table fixed it.
If I understand the change within CASSANDRA-15164 right, then the storage
format of SSTable statistics has changed, which should also bump the SSTable
version, shouldn't it?
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta
>
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229937#comment-17229937
]
Tibor Repasi commented on CASSANDRA-16259:
--
Scrubbing the affected table makes histograms work again.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
>
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229826#comment-17229826
]
Tibor Repasi commented on CASSANDRA-16259:
--
These log messages started after upgrade Apache Cassandra from 3.11.8 to
3.11.9, running Datastax MCAC-Agent 0.1.11 (later upgraded to 0.1.12, without
noticeable change).
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin Montgomery
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
>
[jira] [Commented] (CASSANDRA-16259) tablehistograms cause ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229791#comment-17229791
]
Tibor Repasi commented on CASSANDRA-16259:
--
We have the same issue. Noteworthy observation is that not all tables are
affected, but it's not the table schema, i.e. we have the same tables in
multiple keyspaces, some of them fail histograms in one keyspace, not in the
other.
> tablehistograms cause ArrayIndexOutOfBoundsException
>
>
> Key: CASSANDRA-16259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16259
> Project: Cassandra
> Issue Type: Bug
>Reporter: Justin
>Assignee: Benjamin Lerer
>Priority: Normal
>
> After upgrading some nodes in our cluster from 3.11.8 to 3.11.9 an error
> appeared on the upgraded nodes when trying to access *tablehistograms*. The
> same command run on our .8 nodes return as expected, only the upgraded .9
> nodes fail. Not all tables fail when queried, but about 90% of them do.
> We use Datastax MCAC which appears to query histograms every 30 seconds, this
> outputs to the system.log:
> {noformat}
> WARN [insights-3-1] 2020-11-09 01:11:22,331 UnixSocketClient.java:830 -
> Error reporting:
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> ~[apache-cassandra-3.11.9.jar:3.11.9]
> at
> com.datastax.mcac.UnixSocketClient.writeMetric(UnixSocketClient.java:839)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.access$700(UnixSocketClient.java:78)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient$2.lambda$onGaugeAdded$0(UnixSocketClient.java:626)
> ~[datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.writeGroup(UnixSocketClient.java:819)
> [datastax-mcac-agent.jar:na]
> at
> com.datastax.mcac.UnixSocketClient.lambda$restartMetricReporting$2(UnixSocketClient.java:798)
> [datastax-mcac-agent.jar:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_272]
> at
> io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:126)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:399)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:307)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at
> io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> ~[netty-all-4.0.44.Final.jar:4.0.44.Final]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_272]{noformat}
> Manually trying a histogram from the CLI:
> {noformat}
> $ nodetool tablehistograms logdata log_height_index
> error: 115
> -- StackTrace --
> java.lang.ArrayIndexOutOfBoundsException: 115
> at
> org.apache.cassandra.metrics.TableMetrics.combineHistograms(TableMetrics.java:261)
> at
> org.apache.cassandra.metrics.TableMetrics.access$000(TableMetrics.java:48)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:376)
> at
> org.apache.cassandra.metrics.TableMetrics$11.getValue(TableMetrics.java:373)
> at
> org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxGauge.getValue(CassandraMetricsRegistry.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
>
[jira] [Commented] (CASSANDRA-16127) NullPointerException when calling nodetool enablethrift
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17196730#comment-17196730
]
Tibor Repasi commented on CASSANDRA-16127:
--
Now start and stop are looking much more tidy. Assume that this will also fix
CASSANDRA-16091 .
> NullPointerException when calling nodetool enablethrift
> ---
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Thrift
>Reporter: Tibor Repasi
>Assignee: David Capwell
>Priority: Normal
> Fix For: 2.2.x, 3.0.x, 3.11.x
>
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-16127) NPE on `nodetool enablethrift`
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-16127:
-
Comment: was deleted
(was: Version 3.0.22 is also affected.)
> NPE on `nodetool enablethrift`
> --
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Priority: Normal
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16127) NPE on `nodetool enablethrift`
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195981#comment-17195981
]
Tibor Repasi commented on CASSANDRA-16127:
--
Version 3.0.22 is also affected.
> NPE on `nodetool enablethrift`
> --
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Priority: Normal
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16127) NPE on `nodetool enablethrift`
[
https://issues.apache.org/jira/browse/CASSANDRA-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-16127:
-
Since Version: 3.11.8
> NPE on `nodetool enablethrift`
> --
>
> Key: CASSANDRA-16127
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Priority: Normal
>
> Having thrift disabled, it's impossible to enable it again without restarting
> the node:
> {code}
> $ nodetool statusthrift
> not running
> $ nodetool enablethrift
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16127) NPE on `nodetool enablethrift`
Tibor Repasi created CASSANDRA-16127:
Summary: NPE on `nodetool enablethrift`
Key: CASSANDRA-16127
URL: https://issues.apache.org/jira/browse/CASSANDRA-16127
Project: Cassandra
Issue Type: Bug
Reporter: Tibor Repasi
Having thrift disabled, it's impossible to enable it again without restarting
the node:
{code}
$ nodetool statusthrift
not running
$ nodetool enablethrift
error: null
-- StackTrace --
java.lang.NullPointerException
at
org.apache.cassandra.service.StorageService.startRPCServer(StorageService.java:392)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16124) nodetool enablebinary throws exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195979#comment-17195979
]
Tibor Repasi commented on CASSANDRA-16124:
--
Version 3.0.22 is also affected.
> nodetool enablebinary throws exception
> --
>
> Key: CASSANDRA-16124
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16124
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tommy Stendahl
>Priority: Normal
>
> I think there is a bug in 3.11.8, if you disable the Native port its not
> possible to enable it (without restarting Cassandra).
> {quote}> nodetool statusbinary
> running
> > nodetool disablebinary
> > nodetool statusbinary
> not running
> > nodetool enablebinary
> error: Error starting native transport: setup() must be called first for
> CassandraDaemon
> – StackTrace –
> java.lang.RuntimeException: Error starting native transport: setup() must be
> called first for CassandraDaemon
> at
> org.apache.cassandra.service.StorageService.startNativeTransport(StorageService.java:429)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {quote}
> I think this was introduced with CASSANDRA-15967. In
> {{CassandraDaemon.stopNativeTransport()}} {{nativeTransportService}} is set
> to {{null}} and when {{CassandraDaemon.startNativeTransport()}} is called the
> exception is thrown. By adding a call to
> {{CassandraDaemon.initializeNativeTransport()}} before calling
> {{CassandraDaemon.startNativeTransport()}} works but I'm not sure what the
> intention here is.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17195978#comment-17195978
]
Tibor Repasi commented on CASSANDRA-16091:
--
Version 3.0.22 is also affected.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194148#comment-17194148
]
Tibor Repasi commented on CASSANDRA-16091:
--
As a work around, it seems to be safe to disable thrift after a node has
started up.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189163#comment-17189163
]
Tibor Repasi commented on CASSANDRA-16091:
--
As far as I see, thrift was used to be startet at
[CassandraDaemon.java#L546|https://github.com/apache/cassandra/blob/ca37de06ef9760e6dec26e7d443625bc6a9bbc7b/src/java/org/apache/cassandra/service/CassandraDaemon.java#L546]
which is guarded by config property {{cassandra.start_rpc}}.
In the current release,
[CassandraDaemon.java#L713|https://github.com/apache/cassandra/blob/ca37de06ef9760e6dec26e7d443625bc6a9bbc7b/src/java/org/apache/cassandra/service/CassandraDaemon.java#L713]
is also starting the thrift server if native transport is enabled.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189132#comment-17189132
]
Tibor Repasi edited comment on CASSANDRA-16091 at 9/2/20, 10:28 AM:
We also have a similar, strange behaviour, however without exceptions, after
upgrading to 3.11.8, with enabled thrift while having start_rpc disabled in
config:
{code:java}
INFO [main] 2020-09-02 11:59:17,892 YamlConfigurationLoader.java:89 -
Configuration location: file:/etc/cassandra/cassandra.yaml
INFO [main] 2020-09-02 11:59:18,182 Config.java:536 - Node configuration:[...
rpc_address=0.0.0.0; rpc_interface=null; rpc_interface_prefer_ipv6=false;
rpc_keepalive=true; rpc_listen_backlog=50; rpc_max_threads=2147483647;
rpc_min_threads=16; rpc_port=9160; rpc_recv_buff_size_in_bytes=null;
rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
start_native_transport=true; start_rpc=false; ...
thrift_framed_transport_size_in_mb=15; thrift_max_message_length_in_mb=16;
thrift_prepared_statements_cache_size_mb=null; ...]
...
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:663 - Cassandra
version: 3.11.8
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:664 - Thrift API
version: 20.1.0
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:665 - CQL supported
versions: 3.4.4 (default: 3.4.4)
...
INFO [main] 2020-09-02 11:59:33,491 Server.java:159 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2020-09-02 11:59:33,543 ThriftServer.java:116 - Binding thrift
service to /0.0.0.0:9160
INFO [Thread-8] 2020-09-02 11:59:33,549 ThriftServer.java:133 - Listening for
thrift clients...
INFO [main] 2020-09-02 11:59:33,553 CassandraDaemon.java:548 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
{code}
{code:java}
$ nodetool info
ID : 232f4fe3-051a-4488-97c1-062b733b63e4
Gossip active : true
Thrift active : true
Native Transport active: true
...
{code}
Especially, the last two log entries seem inconsistent.
was (Author: rtib):
We also have a similar, strange behaviour after upgrading to 3.11.8, with
enabled thrift while having start_rpc disabled in config:
{code}
INFO [main] 2020-09-02 11:59:17,892 YamlConfigurationLoader.java:89 -
Configuration location: file:/etc/cassandra/cassandra.yaml
INFO [main] 2020-09-02 11:59:18,182 Config.java:536 - Node configuration:[...
rpc_address=0.0.0.0; rpc_interface=null; rpc_interface_prefer_ipv6=false;
rpc_keepalive=true; rpc_listen_backlog=50; rpc_max_threads=2147483647;
rpc_min_threads=16; rpc_port=9160; rpc_recv_buff_size_in_bytes=null;
rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
start_native_transport=true; start_rpc=false; ...
thrift_framed_transport_size_in_mb=15; thrift_max_message_length_in_mb=16;
thrift_prepared_statements_cache_size_mb=null; ...]
...
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:663 - Cassandra
version: 3.11.8
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:664 - Thrift API
version: 20.1.0
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:665 - CQL supported
versions: 3.4.4 (default: 3.4.4)
...
INFO [main] 2020-09-02 11:59:33,491 Server.java:159 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2020-09-02 11:59:33,543 ThriftServer.java:116 - Binding thrift
service to /0.0.0.0:9160
INFO [Thread-8] 2020-09-02 11:59:33,549 ThriftServer.java:133 - Listening for
thrift clients...
INFO [main] 2020-09-02 11:59:33,553 CassandraDaemon.java:548 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
{code}
{code}
$ nodetool info
ID : 232f4fe3-051a-4488-97c1-062b733b63e4
Gossip active : true
Thrift active : true
Native Transport active: true
...
{code}
Especially, the last two log entries seem inconsistent.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
>
[jira] [Commented] (CASSANDRA-16091) rpc server gets wrongly initialized with rpc_enabled:false
[
https://issues.apache.org/jira/browse/CASSANDRA-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189132#comment-17189132
]
Tibor Repasi commented on CASSANDRA-16091:
--
We also have a similar, strange behaviour after upgrading to 3.11.8, with
enabled thrift while having start_rpc disabled in config:
{code}
INFO [main] 2020-09-02 11:59:17,892 YamlConfigurationLoader.java:89 -
Configuration location: file:/etc/cassandra/cassandra.yaml
INFO [main] 2020-09-02 11:59:18,182 Config.java:536 - Node configuration:[...
rpc_address=0.0.0.0; rpc_interface=null; rpc_interface_prefer_ipv6=false;
rpc_keepalive=true; rpc_listen_backlog=50; rpc_max_threads=2147483647;
rpc_min_threads=16; rpc_port=9160; rpc_recv_buff_size_in_bytes=null;
rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
start_native_transport=true; start_rpc=false; ...
thrift_framed_transport_size_in_mb=15; thrift_max_message_length_in_mb=16;
thrift_prepared_statements_cache_size_mb=null; ...]
...
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:663 - Cassandra
version: 3.11.8
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:664 - Thrift API
version: 20.1.0
INFO [main] 2020-09-02 11:59:23,337 StorageService.java:665 - CQL supported
versions: 3.4.4 (default: 3.4.4)
...
INFO [main] 2020-09-02 11:59:33,491 Server.java:159 - Starting listening for
CQL clients on /0.0.0.0:9042 (unencrypted)...
INFO [main] 2020-09-02 11:59:33,543 ThriftServer.java:116 - Binding thrift
service to /0.0.0.0:9160
INFO [Thread-8] 2020-09-02 11:59:33,549 ThriftServer.java:133 - Listening for
thrift clients...
INFO [main] 2020-09-02 11:59:33,553 CassandraDaemon.java:548 - Not starting
RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool
(enablethrift) to start it
{code}
{code}
$ nodetool info
ID : 232f4fe3-051a-4488-97c1-062b733b63e4
Gossip active : true
Thrift active : true
Native Transport active: true
...
{code}
Especially, the last two log entries seem inconsistent.
> rpc server gets wrongly initialized with rpc_enabled:false
> --
>
> Key: CASSANDRA-16091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16091
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Tom van der Woerdt
>Priority: Normal
> Fix For: 3.11.9
>
>
> After upgrading to Cassandra 3.11.8, Cassandra no longer starts. An exception
> is thrown:
> {code:java}
> java.lang.RuntimeException: Client SSL is not supported for non-blocking
> sockets (hsha). Please remove client ssl from the configuration.
> at
> org.apache.cassandra.thrift.THsHaDisruptorServer$Factory.buildTServer(THsHaDisruptorServer.java:74)
> at
> org.apache.cassandra.thrift.TServerCustomFactory.buildTServer(TServerCustomFactory.java:55)
> at
> org.apache.cassandra.thrift.ThriftServer$ThriftServerThread.(ThriftServer.java:128)
> at org.apache.cassandra.thrift.ThriftServer.start(ThriftServer.java:55)
> at
> org.apache.cassandra.service.CassandraDaemon.startNativeTransport(CassandraDaemon.java:713)
> at
> org.apache.cassandra.service.CassandraDaemon.start(CassandraDaemon.java:538)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:643)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:768)
> {code}
> No configuration changed between 3.11.7 and 3.11.8. rpc_enabled is false in
> both versions.
> I created this Jira issue because clearly something changed between 3.11.7
> and 3.11.8. Maybe intentional, maybe not. Changing `rpc_server_type` (which
> is not clearly documented to be about Thrift only) from `hsha` to `sync` does
> resolve the issue, as expected, but this does seem like a regression, hence
> the Jira issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14811) RPC_READY flag handled inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-14811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-14811:
-
Component/s: (was: Legacy/Distributed Metadata)
> RPC_READY flag handled inconsistently
> -
>
> Key: CASSANDRA-14811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14811
> Project: Cassandra
> Issue Type: Bug
>Reporter: Tibor Repasi
>Priority: Normal
>
> With version 3.0.17 we experience an inconsistent handling of the RPC_READY
> flag. We identified 3 scenarios with an unexpected behaviour.
> # Using {{nodetool disablebinary}} on a node in normal operation
> ** Observed behaviour:
> *** (/) the CQL listener is closed and Netty shut down
> *** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
> ** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
> switch to *false.* This is what we observe with version 2.2.13
> # Starting up a node with JVM option
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is not started to listen for CQL clients
> *** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native
> transport as requested. Use JMX (StorageService->startNativeTransport()) or
> nodetool (enablebinary) to start it}}
> *** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
> however, this is also observed on 2.2.13.
> # Issuing {{nodetool enablebinary}} command on a node started with
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is started up and open the CQL port for listening
> *** (x) the {{RPC_READY}} flag is not announced for this node any more,
> causing clients to not consider this node up and not trying to connect.
> ** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
> *true*, as observed with version 2.2.13.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14811) RPC_READY flag handled inconsistently
[
https://issues.apache.org/jira/browse/CASSANDRA-14811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-14811:
-
Description:
With version 3.0.17 we experience an inconsistent handling of the RPC_READY
flag. We identified 3 scenarios with an unexpected behaviour.
# Using {{nodetool disablebinary}} on a node in normal operation
** Observed behaviour:
*** (/) the CQL listener is closed and Netty shut down
*** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
switch to *false.* This is what we observe with version 2.2.13
# Starting up a node with JVM option
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is not started to listen for CQL clients
*** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native transport
as requested. Use JMX (StorageService->startNativeTransport()) or nodetool
(enablebinary) to start it}}
*** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
however, this is also observed on 2.2.13.
# Issuing {{nodetool enablebinary}} command on a node started with
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is started up and open the CQL port for listening
*** (x) the {{RPC_READY}} flag is not announced for this node any more,
causing clients to not consider this node up and not trying to connect.
** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
*true*, as observed with version 2.2.13.
was:
With version 3.0.17 we experience an inconsistent handling of the RPC_READY
flag. We identified 3 scenarios with an unexpected behaviour.
# Using {{nodetool disablebinary}} on a node in normal operation
** Observed behaviour:
*** (/) the CQL listener is closed and Netty shut down
*** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
switch to *false.* This is what we observe with version 2.2.13
# Starting up a node with JVM option
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is not started to listen for CQL clients
*** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native transport
as requested. Use JMX (StorageService->startNativeTransport()) or nodetool
(enablebinary) to start it}}
*** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
however, this is also observed on 2.2.13.
# Issuing {{nodetool enablebinary}} command on a node started with
{{-Dcassandra.start_native_transport=false}}
** Observed behaviour:
*** (/) Netty is started up and open the CQL port for listening
*** (x) the {{RPC_READY}} flag is not announced for this node any more,
causing clients to not consider this note up and not trying to connect.
** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
*true*, as observed with version 2.2.13.
> RPC_READY flag handled inconsistently
> -
>
> Key: CASSANDRA-14811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14811
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Tibor Repasi
>Priority: Major
>
> With version 3.0.17 we experience an inconsistent handling of the RPC_READY
> flag. We identified 3 scenarios with an unexpected behaviour.
> # Using {{nodetool disablebinary}} on a node in normal operation
> ** Observed behaviour:
> *** (/) the CQL listener is closed and Netty shut down
> *** (x) gossipinfo still contain the {{RPC_READY}} *true* advertisement.
> ** Expected behaviour: gossip announcement of the {{RPC_READY}} flag should
> switch to *false.* This is what we observe with version 2.2.13
> # Starting up a node with JVM option
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is not started to listen for CQL clients
> *** (/) logging {{cassandra[1765]: INFO 13:58:46 Not starting native
> transport as requested. Use JMX (StorageService->startNativeTransport()) or
> nodetool (enablebinary) to start it}}
> *** (?) the gossipinfo does not contain the {{RPC_READY}} flag at all,
> however, this is also observed on 2.2.13.
> # Issuing {{nodetool enablebinary}} command on a node started with
> {{-Dcassandra.start_native_transport=false}}
> ** Observed behaviour:
> *** (/) Netty is started up and open the CQL port for listening
> *** (x) the {{RPC_READY}} flag is not announced for this node any more,
> causing clients to not consider this node up and not trying to connect.
> ** Expected behaviour: gossip flag {{RPC_READY}} should be added to announce
> *true*, as observed with version 2.2.13.
>
--
This message was
