[jira] [Commented] (CASSANDRA-19255) StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces
[ https://issues.apache.org/jira/browse/CASSANDRA-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829829#comment-17829829 ] n.v.harikrishna commented on CASSANDRA-19255: - Thanks [~marcuse] & [~samt] ! > StorageService.getRangeToEndpointMap() MBean operation is running into NPE > for LocalStrategy keysapces > -- > > Key: CASSANDRA-19255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19255 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Attachments: 19482_patch_for_19255.diff, ci_summary.html, > result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > When the StorageService's MBean operation getRangeToEndpointMap is called for > LocalStrategy keyspaces, then it is running into NPE. It is working in > earlier major version, but failing in trunk. It can be reproduced in local > using JConsole or using a tool like `jmxterm` (unfortunately these tools are > not giving full stacktrace). Observed the same behavior with > getRangeToEndpointWithPortMap operation too. -- This message was sent by Atlassian Jira (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-19255) StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces
[ https://issues.apache.org/jira/browse/CASSANDRA-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna updated CASSANDRA-19255: Test and Documentation Plan: Verified in local and ran tests. Status: Patch Available (was: Open) Uploaded the test results. [PR|http://example.com|https://github.com/apache/cassandra/pull/3141] > StorageService.getRangeToEndpointMap() MBean operation is running into NPE > for LocalStrategy keysapces > -- > > Key: CASSANDRA-19255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19255 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > When the StorageService's MBean operation getRangeToEndpointMap is called for > LocalStrategy keyspaces, then it is running into NPE. It is working in > earlier major version, but failing in trunk. It can be reproduced in local > using JConsole or using a tool like `jmxterm` (unfortunately these tools are > not giving full stacktrace). Observed the same behavior with > getRangeToEndpointWithPortMap operation too. -- This message was sent by Atlassian Jira (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-19255) StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces
[ https://issues.apache.org/jira/browse/CASSANDRA-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna updated CASSANDRA-19255: Attachment: ci_summary.html > StorageService.getRangeToEndpointMap() MBean operation is running into NPE > for LocalStrategy keysapces > -- > > Key: CASSANDRA-19255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19255 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > When the StorageService's MBean operation getRangeToEndpointMap is called for > LocalStrategy keyspaces, then it is running into NPE. It is working in > earlier major version, but failing in trunk. It can be reproduced in local > using JConsole or using a tool like `jmxterm` (unfortunately these tools are > not giving full stacktrace). Observed the same behavior with > getRangeToEndpointWithPortMap operation too. -- This message was sent by Atlassian Jira (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-19255) StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces
[ https://issues.apache.org/jira/browse/CASSANDRA-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna updated CASSANDRA-19255: Attachment: result_details.tar.gz > StorageService.getRangeToEndpointMap() MBean operation is running into NPE > for LocalStrategy keysapces > -- > > Key: CASSANDRA-19255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19255 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > When the StorageService's MBean operation getRangeToEndpointMap is called for > LocalStrategy keyspaces, then it is running into NPE. It is working in > earlier major version, but failing in trunk. It can be reproduced in local > using JConsole or using a tool like `jmxterm` (unfortunately these tools are > not giving full stacktrace). Observed the same behavior with > getRangeToEndpointWithPortMap operation too. -- This message was sent by Atlassian Jira (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-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827380#comment-17827380 ] n.v.harikrishna commented on CASSANDRA-19393: - Thanks [~smiklosovic] ! And apologies for the slow trun around. > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.1 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (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-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825983#comment-17825983 ] n.v.harikrishna commented on CASSANDRA-19393: - There are couple of places where "initializecms" is used in python dtests. [https://github.com/search?q=repo%3Aapache%2Fcassandra-dtest%20initializecms=code] . Making changes there as well and checking other commands. > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (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-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818134#comment-17818134 ] n.v.harikrishna commented on CASSANDRA-19393: - [~smiklosovic] pushed the changes. > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (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-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818065#comment-17818065 ] n.v.harikrishna commented on CASSANDRA-19393: - Thanks for the review. Sure, will add the commit and update documentation. > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (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-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna updated CASSANDRA-19393: Test and Documentation Plan: * Tested CMS commands locally. * Tested the impacted test cases (for which the node tool command has to be changed) * [CI|https://app.circleci.com/pipelines/github/nvharikrishna/cassandra/79/workflows/4d4e40ab-0377-4f47-8f0f-b0ade623d375] Status: Patch Available (was: Open) PR: [trunk|https://github.com/apache/cassandra/pull/3101] > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (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-19393) nodetool: group CMS-related commands into one command
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817363#comment-17817363 ] n.v.harikrishna commented on CASSANDRA-19393: - Thanks you all for the inputs! I will update the PR as per the discussion. > nodetool: group CMS-related commands into one command > - > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool, Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > The purpose of this ticket is to group all CMS-related commands under one > "nodetool cms" command where existing command would be subcommands of it. -- This message was sent by Atlassian Jira (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-19393) Introduce nodetool command to dump cluster metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817315#comment-17817315 ] n.v.harikrishna commented on CASSANDRA-19393: - The current dump command calls `CMSOperations.dumpClusterMetadata` mbean which dumps the serialized metadata to a file and this command just prints the file location. Printing metadata probably can go as part of CASSANDRA-19151 (another ticket I'm working on)? There I can make it to print as JSON/YAML format. > Introduce nodetool command to dump cluster metadata > --- > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Adding a nodetool command for dumping cluster metadata would be handy when > compared to making a JMX call. Nodetool has two more commands related to > cluster metadata service (describecms and reconfigurecms). These commands can > be grouped for simplicity. -- This message was sent by Atlassian Jira (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-19393) Introduce nodetool command to dump cluster metadata
[ https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817296#comment-17817296 ] n.v.harikrishna commented on CASSANDRA-19393: - Raised PR with the changes: [https://github.com/apache/cassandra/pull/3101] Just realized that there is one more command `initializecms`. It can be moved too under the same command group if agreed. > Introduce nodetool command to dump cluster metadata > --- > > Key: CASSANDRA-19393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Adding a nodetool command for dumping cluster metadata would be handy when > compared to making a JMX call. Nodetool has two more commands related to > cluster metadata service (describecms and reconfigurecms). These commands can > be grouped for simplicity. -- This message was sent by Atlassian Jira (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-19393) Introduce nodetool command to dump cluster metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817289#comment-17817289
]
n.v.harikrishna commented on CASSANDRA-19393:
-
Sorry! I think I did not mention clearly in the description. I mean to make all
cms related commands as sub commands under command group "cms" so that it would
look something like:
{code:java}
nodetool cms describe
nodetool cms reconfigure
nodetool cms dump
{code}
> Introduce nodetool command to dump cluster metadata
> ---
>
> Key: CASSANDRA-19393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19393
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> Adding a nodetool command for dumping cluster metadata would be handy when
> compared to making a JMX call. Nodetool has two more commands related to
> cluster metadata service (describecms and reconfigurecms). These commands can
> be grouped for simplicity.
--
This message was sent by Atlassian Jira
(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-19393) Introduce nodetool command to dump cluster metadata
[
https://issues.apache.org/jira/browse/CASSANDRA-19393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817289#comment-17817289
]
n.v.harikrishna edited comment on CASSANDRA-19393 at 2/14/24 9:47 AM:
--
Sorry! I think I did not mention clearly in the description. I mean to make all
cms related commands as sub commands under command group "cms" so that it would
look something like:
{code:java}
nodetool cms describe
nodetool cms reconfigure
nodetool cms dump
{code}
was (Author: n.v.harikrishna):
Sorry! I think I did not mention clearly in the description. I mean to make all
cms related commands as sub commands under command group "cms" so that it would
look something like:
{code:java}
nodetool cms describe
nodetool cms reconfigure
nodetool cms dump
{code}
> Introduce nodetool command to dump cluster metadata
> ---
>
> Key: CASSANDRA-19393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19393
> Project: Cassandra
> Issue Type: Improvement
> Components: Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> Adding a nodetool command for dumping cluster metadata would be handy when
> compared to making a JMX call. Nodetool has two more commands related to
> cluster metadata service (describecms and reconfigurecms). These commands can
> be grouped for simplicity.
--
This message was sent by Atlassian Jira
(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-19393) Introduce nodetool command to dump cluster metadata
n.v.harikrishna created CASSANDRA-19393: --- Summary: Introduce nodetool command to dump cluster metadata Key: CASSANDRA-19393 URL: https://issues.apache.org/jira/browse/CASSANDRA-19393 Project: Cassandra Issue Type: Improvement Components: Transactional Cluster Metadata Reporter: n.v.harikrishna Assignee: n.v.harikrishna Adding a nodetool command for dumping cluster metadata would be handy when compared to makinga JMX call. Nodetool has two more commands related to cluster metadata service (describecms and reconfigurecms). These commands can be grouped for simplicity. -- This message was sent by Atlassian Jira (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-19255) StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces
[ https://issues.apache.org/jira/browse/CASSANDRA-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804820#comment-17804820 ] n.v.harikrishna commented on CASSANDRA-19255: - Suspecting that similar issue exists for other getRangeTo* operations of StorageService. Will cross check them too. > StorageService.getRangeToEndpointMap() MBean operation is running into NPE > for LocalStrategy keysapces > -- > > Key: CASSANDRA-19255 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19255 > Project: Cassandra > Issue Type: Bug >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > > When the StorageService's MBean operation getRangeToEndpointMap is called for > LocalStrategy keyspaces, then it is running into NPE. It is working in > earlier major version, but failing in trunk. It can be reproduced in local > using JConsole or using a tool like `jmxterm` (unfortunately these tools are > not giving full stacktrace). Observed the same behavior with > getRangeToEndpointWithPortMap operation too. -- This message was sent by Atlassian Jira (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-19255) StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces
n.v.harikrishna created CASSANDRA-19255: --- Summary: StorageService.getRangeToEndpointMap() MBean operation is running into NPE for LocalStrategy keysapces Key: CASSANDRA-19255 URL: https://issues.apache.org/jira/browse/CASSANDRA-19255 Project: Cassandra Issue Type: Bug Reporter: n.v.harikrishna Assignee: n.v.harikrishna When the StorageService's MBean operation getRangeToEndpointMap is called for LocalStrategy keyspaces, then it is running into NPE. It is working in earlier major version, but failing in trunk. It can be reproduced in local using JConsole or using a tool like `jmxterm` (unfortunately these tools are not giving full stacktrace). Observed the same behavior with getRangeToEndpointWithPortMap operation too. -- This message was sent by Atlassian Jira (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-19247) Minor corrections to TCM Implementation documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
n.v.harikrishna updated CASSANDRA-19247:
Test and Documentation Plan: Minor documentation (with in GitHub) change.
Status: Patch Available (was: Open)
Patch available in [pr 3028|https://github.com/apache/cassandra/pull/3028].
> Minor corrections to TCM Implementation documentation
> -
>
> Key: CASSANDRA-19247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> In the "[Bootstrap: InProgressSequence, PrepareJoin,
> BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
> section of TCM Implementation doc, InProgressSequence transformations are
> mentioned as "{_}InProgressSequence`, holding the three transformations
> (`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
> [PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
> these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be
> updated.
>
--
This message was sent by Atlassian Jira
(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-19247) Minor corrections to TCM Implementation documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803257#comment-17803257
]
n.v.harikrishna commented on CASSANDRA-19247:
-
Raised [PR|https://github.com/apache/cassandra/pull/3028] with the chagnes.
> Minor corrections to TCM Implementation documentation
> -
>
> Key: CASSANDRA-19247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Transactional Cluster Metadata
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> In the "[Bootstrap: InProgressSequence, PrepareJoin,
> BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
> section of TCM Implementation doc, InProgressSequence transformations are
> mentioned as "{_}InProgressSequence`, holding the three transformations
> (`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
> [PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
> these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be
> updated.
>
--
This message was sent by Atlassian Jira
(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-19247) Minor corrections to TCM Implementation documentation
n.v.harikrishna created CASSANDRA-19247:
---
Summary: Minor corrections to TCM Implementation documentation
Key: CASSANDRA-19247
URL: https://issues.apache.org/jira/browse/CASSANDRA-19247
Project: Cassandra
Issue Type: Bug
Components: Documentation, Transactional Cluster Metadata
Reporter: n.v.harikrishna
Assignee: n.v.harikrishna
In the "[Bootstrap: InProgressSequence, PrepareJoin,
BootstrapAndJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/TCM_implementation.md#bootstrap-inprogresssequence-preparejoin-bootstrapandjoin]”
section of TCM Implementation doc, InProgressSequence transformations are
mentioned as "{_}InProgressSequence`, holding the three transformations
(`PrepareJoin`, `MinJoin` `FinishJoin`){_}”. As per
[PrepareJoin|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tcm/transformations/PrepareJoin.java#L154],
these are {*}StartJoin{*}, Mi{*}d{*}Join & FinishJoin. Doc needs to be updated.
--
This message was sent by Atlassian Jira
(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] (CASSANDRASC-91) AbstractHandler is handling the request even when it fails to extract params
[ https://issues.apache.org/jira/browse/CASSANDRASC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17801181#comment-17801181 ] n.v.harikrishna commented on CASSANDRASC-91: [CI|https://app.circleci.com/pipelines/github/nvharikrishna/cassandra-sidecar/3/workflows/25a5c824-afad-4f13-b26a-67d33fa5f299] passed. > AbstractHandler is handling the request even when it fails to extract params > > > Key: CASSANDRASC-91 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-91 > Project: Sidecar for Apache Cassandra > Issue Type: Bug >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Labels: pull-request-available > > AbstractHandler’s handle method is calling extractParamsOrThrow method to > parse the request which can fail with HttpException (a runtime exception). > When extraction fails, then AbstractHandler is processing the failure using > processFailure method and continued to call handleInternal method. Calling > handlerInternal even when failed to extract params resulting unwanted > results. If the extraction of parameters failes, then AbstractHandler should > not call handleInternal. > > Example: > Passing an invalid character for ring route per keysapce endpoint (handled by > RingHandler which is extending AbstractHandler) something like : > [localhost1:9043/api/v1/cassandra/ring/keyspaces/keysapce%60] is resulting to > _Bad Request_ response, but also resulting NPE from the > RingHandler.handleInternal method > > java.lang.NullPointerException: null > at > org.apache.cassandra.sidecar.routes.RingHandler.lambda$handleInternal$0(RingHandler.java:83) > at > io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180) > at > io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277) > at > io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199) > at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > > It should terminate processing the request when it could not parse the > keyspace. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-91) AbstractHandler is handling the request even when it fails to extract params
[ https://issues.apache.org/jira/browse/CASSANDRASC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800915#comment-17800915 ] n.v.harikrishna commented on CASSANDRASC-91: Raised pr: [CASSANDRASC-91 Returning when AbstractHandler encounters exception while extracting params from the request. by nvharikrishna · Pull Request #88 · apache/cassandra-sidecar (github.com)|https://github.com/apache/cassandra-sidecar/pull/88] > AbstractHandler is handling the request even when it fails to extract params > > > Key: CASSANDRASC-91 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-91 > Project: Sidecar for Apache Cassandra > Issue Type: Bug >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Labels: pull-request-available > > AbstractHandler’s handle method is calling extractParamsOrThrow method to > parse the request which can fail with HttpException (a runtime exception). > When extraction fails, then AbstractHandler is processing the failure using > processFailure method and continued to call handleInternal method. Calling > handlerInternal even when failed to extract params resulting unwanted > results. If the extraction of parameters failes, then AbstractHandler should > not call handleInternal. > > Example: > Passing an invalid character for ring route per keysapce endpoint (handled by > RingHandler which is extending AbstractHandler) something like : > [localhost1:9043/api/v1/cassandra/ring/keyspaces/keysapce%60] is resulting to > _Bad Request_ response, but also resulting NPE from the > RingHandler.handleInternal method > > java.lang.NullPointerException: null > at > org.apache.cassandra.sidecar.routes.RingHandler.lambda$handleInternal$0(RingHandler.java:83) > at > io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180) > at > io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277) > at > io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199) > at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > > It should terminate processing the request when it could not parse the > keyspace. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-91) AbstractHandler is handling the request even when it fails to extract params
n.v.harikrishna created CASSANDRASC-91: -- Summary: AbstractHandler is handling the request even when it fails to extract params Key: CASSANDRASC-91 URL: https://issues.apache.org/jira/browse/CASSANDRASC-91 Project: Sidecar for Apache Cassandra Issue Type: Bug Reporter: n.v.harikrishna Assignee: n.v.harikrishna AbstractHandler’s handle method is calling extractParamsOrThrow method to parse the request which can fail with HttpException (a runtime exception). When extraction fails, then AbstractHandler is processing the failure using processFailure method and continued to call handleInternal method. Calling handlerInternal even when failed to extract params resulting unwanted results. If the extraction of parameters failes, then AbstractHandler should not call handleInternal. Example: Passing an invalid character for ring route per keysapce endpoint (handled by RingHandler which is extending AbstractHandler) something like : [localhost1:9043/api/v1/cassandra/ring/keyspaces/keysapce%60] is resulting to _Bad Request_ response, but also resulting NPE from the RingHandler.handleInternal method java.lang.NullPointerException: null at org.apache.cassandra.sidecar.routes.RingHandler.lambda$handleInternal$0(RingHandler.java:83) at io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180) at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277) at io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199) at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) It should terminate processing the request when it could not parse the keyspace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19151) Add an offline cluster metadata tool for disaster recovery scenarios
[ https://issues.apache.org/jira/browse/CASSANDRA-19151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna reassigned CASSANDRA-19151: --- Assignee: n.v.harikrishna > Add an offline cluster metadata tool for disaster recovery scenarios > > > Key: CASSANDRA-19151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19151 > Project: Cassandra > Issue Type: Improvement >Reporter: Alex Petrov >Assignee: n.v.harikrishna >Priority: Normal > > We currently have an offline tool to make a node CMS > We should add a tool (or update the existing one) to > * completely forget a node id > * add an instance at a given token > * force move a nodeid to JOINED > * dump the cluster metadata in a human readable format -- This message was sent by Atlassian Jira (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-19151) Add an offline cluster metadata tool for disaster recovery scenarios
[ https://issues.apache.org/jira/browse/CASSANDRA-19151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793558#comment-17793558 ] n.v.harikrishna commented on CASSANDRA-19151: - I can pick it. > Add an offline cluster metadata tool for disaster recovery scenarios > > > Key: CASSANDRA-19151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19151 > Project: Cassandra > Issue Type: Improvement >Reporter: Alex Petrov >Priority: Normal > > We currently have an offline tool to make a node CMS > We should add a tool (or update the existing one) to > * completely forget a node id > * add an instance at a given token > * force move a nodeid to JOINED > * dump the cluster metadata in a human readable format -- This message was sent by Atlassian Jira (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-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17723211#comment-17723211 ] n.v.harikrishna commented on CASSANDRA-18525: - Thanks[~smiklosovic] and[~mck] for the review and the CI links. I could not run CI completely (due to limitations on free account), working on it. > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.0 > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (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-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna updated CASSANDRA-18525: Status: Patch Available (was: In Progress) > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (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-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] n.v.harikrishna updated CASSANDRA-18525: Status: In Progress (was: Changes Suggested) > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (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-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722243#comment-17722243 ] n.v.harikrishna commented on CASSANDRA-18525: - PR for trunk is [here|https://github.com/apache/cassandra/pull/2331]. > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (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-18525) Add keyspace column to clients virtual table
n.v.harikrishna created CASSANDRA-18525: --- Summary: Add keyspace column to clients virtual table Key: CASSANDRA-18525 URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 Project: Cassandra Issue Type: Improvement Reporter: n.v.harikrishna Assignee: n.v.harikrishna Clients virtual table doesn’t have keyspace information. ‘clientstats' nodetool has this information. Adding keyspace column to clients virtual table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (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-18509) Enable single_sstable_uplevel by default for LCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721007#comment-17721007 ] n.v.harikrishna commented on CASSANDRA-18509: - Raised pr for trunk: [https://github.com/apache/cassandra/pull/2317] Will update the CI details soon > Enable single_sstable_uplevel by default for LCS > > > Key: CASSANDRA-18509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18509 > Project: Cassandra > Issue Type: Improvement >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > > Single sstable uplevel option (single_sstable_uplevel) added to LCS with > CASSANDRA-12526 is disabled by default. Considering the performance > improvements is provides, I think it makes sense to enable it by default so > that it can be leveraged without configuring explicitly. -- This message was sent by Atlassian Jira (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-18509) Enable single_sstable_uplevel by default for LCS
n.v.harikrishna created CASSANDRA-18509: --- Summary: Enable single_sstable_uplevel by default for LCS Key: CASSANDRA-18509 URL: https://issues.apache.org/jira/browse/CASSANDRA-18509 Project: Cassandra Issue Type: Improvement Reporter: n.v.harikrishna Assignee: n.v.harikrishna Single sstable uplevel option (single_sstable_uplevel) added to LCS with CASSANDRA-12526 is disabled by default. Considering the performance improvements is provides, I think it makes sense to enable it by default so that it can be leveraged without configuring explicitly. -- This message was sent by Atlassian Jira (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-18215) Fix the output of FQL dump tool to properly separate entries
[
https://issues.apache.org/jira/browse/CASSANDRA-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684550#comment-17684550
]
n.v.harikrishna commented on CASSANDRA-18215:
-
[~smiklosovic] Thanks for taking a look. Added test case and pushed the changes
to PR.
> Fix the output of FQL dump tool to properly separate entries
>
>
> Key: CASSANDRA-18215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18215
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Stefan Miklosovic
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> This was reported in (1)
> (1) https://github.com/apache/cassandra/pull/2050
> If I create a table something like this:
> {code}
> CREATE TABLE t1 ( id int PRIMARY KEY , v1 int, v2 int, v3 int) ;
> {code}
> and inserted a row using:
> {code}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)");
> cqlSession.execute(preparedStatement.bind(1, 1, 1, 1));
> }
> {code}
> The output of fqltool looks something like this:
> {code}
> Type: single-query
> Query start time: 1673373829119
> Protocol version: 5
> Generated timestamp:-9223372036854775808
> Generated nowInSeconds:1673373829
> Query: INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)
> Values:
> 00 00 00 01
> 00 00 00 01
> -
> 00 00 00 01
> -
> 00 00 00 01
> -
> {code}
> - is not printed between the first and second value
> {code}
> Values:
> 00 00 00 01
> 00 00 00 01
> {code}
> We are normally very cautious about changing the output of the tooling but in
> this case I think this is a legit bug which should be fixed.
--
This message was sent by Atlassian Jira
(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-18215) Fix the output of FQL dump tool to properly separate entries
[
https://issues.apache.org/jira/browse/CASSANDRA-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
n.v.harikrishna updated CASSANDRA-18215:
Test and Documentation Plan: Manually verified the output. Mentioned output
before and after this change in the pull request.
Status: Patch Available (was: Open)
PR: https://github.com/apache/cassandra/pull/2135
> Fix the output of FQL dump tool to properly separate entries
>
>
> Key: CASSANDRA-18215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18215
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Stefan Miklosovic
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> This was reported in (1)
> (1) https://github.com/apache/cassandra/pull/2050
> If I create a table something like this:
> {code}
> CREATE TABLE t1 ( id int PRIMARY KEY , v1 int, v2 int, v3 int) ;
> {code}
> and inserted a row using:
> {code}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)");
> cqlSession.execute(preparedStatement.bind(1, 1, 1, 1));
> }
> {code}
> The output of fqltool looks something like this:
> {code}
> Type: single-query
> Query start time: 1673373829119
> Protocol version: 5
> Generated timestamp:-9223372036854775808
> Generated nowInSeconds:1673373829
> Query: INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)
> Values:
> 00 00 00 01
> 00 00 00 01
> -
> 00 00 00 01
> -
> 00 00 00 01
> -
> {code}
> - is not printed between the first and second value
> {code}
> Values:
> 00 00 00 01
> 00 00 00 01
> {code}
> We are normally very cautious about changing the output of the tooling but in
> this case I think this is a legit bug which should be fixed.
--
This message was sent by Atlassian Jira
(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-18215) Fix the output of FQL dump tool to properly separate entries
[
https://issues.apache.org/jira/browse/CASSANDRA-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683992#comment-17683992
]
n.v.harikrishna commented on CASSANDRA-18215:
-
Raised PR with the changes. https://github.com/apache/cassandra/pull/2135
> Fix the output of FQL dump tool to properly separate entries
>
>
> Key: CASSANDRA-18215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18215
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Stefan Miklosovic
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> This was reported in (1)
> (1) https://github.com/apache/cassandra/pull/2050
> If I create a table something like this:
> {code}
> CREATE TABLE t1 ( id int PRIMARY KEY , v1 int, v2 int, v3 int) ;
> {code}
> and inserted a row using:
> {code}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)");
> cqlSession.execute(preparedStatement.bind(1, 1, 1, 1));
> }
> {code}
> The output of fqltool looks something like this:
> {code}
> Type: single-query
> Query start time: 1673373829119
> Protocol version: 5
> Generated timestamp:-9223372036854775808
> Generated nowInSeconds:1673373829
> Query: INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)
> Values:
> 00 00 00 01
> 00 00 00 01
> -
> 00 00 00 01
> -
> 00 00 00 01
> -
> {code}
> - is not printed between the first and second value
> {code}
> Values:
> 00 00 00 01
> 00 00 00 01
> {code}
> We are normally very cautious about changing the output of the tooling but in
> this case I think this is a legit bug which should be fixed.
--
This message was sent by Atlassian Jira
(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-18215) Fix the output of FQL dump tool to properly separate entries
[
https://issues.apache.org/jira/browse/CASSANDRA-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17683653#comment-17683653
]
n.v.harikrishna commented on CASSANDRA-18215:
-
Thanks! I will update the patch details soon.
> Fix the output of FQL dump tool to properly separate entries
>
>
> Key: CASSANDRA-18215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18215
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Stefan Miklosovic
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> This was reported in (1)
> (1) https://github.com/apache/cassandra/pull/2050
> If I create a table something like this:
> {code}
> CREATE TABLE t1 ( id int PRIMARY KEY , v1 int, v2 int, v3 int) ;
> {code}
> and inserted a row using:
> {code}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)");
> cqlSession.execute(preparedStatement.bind(1, 1, 1, 1));
> }
> {code}
> The output of fqltool looks something like this:
> {code}
> Type: single-query
> Query start time: 1673373829119
> Protocol version: 5
> Generated timestamp:-9223372036854775808
> Generated nowInSeconds:1673373829
> Query: INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)
> Values:
> 00 00 00 01
> 00 00 00 01
> -
> 00 00 00 01
> -
> 00 00 00 01
> -
> {code}
> - is not printed between the first and second value
> {code}
> Values:
> 00 00 00 01
> 00 00 00 01
> {code}
> We are normally very cautious about changing the output of the tooling but in
> this case I think this is a legit bug which should be fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18215) Fix the output of FQL dump tool to properly separate entries
[
https://issues.apache.org/jira/browse/CASSANDRA-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
n.v.harikrishna reassigned CASSANDRA-18215:
---
Assignee: n.v.harikrishna
> Fix the output of FQL dump tool to properly separate entries
>
>
> Key: CASSANDRA-18215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18215
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Stefan Miklosovic
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> This was reported in (1)
> (1) https://github.com/apache/cassandra/pull/2050
> If I create a table something like this:
> {code}
> CREATE TABLE t1 ( id int PRIMARY KEY , v1 int, v2 int, v3 int) ;
> {code}
> and inserted a row using:
> {code}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)");
> cqlSession.execute(preparedStatement.bind(1, 1, 1, 1));
> }
> {code}
> The output of fqltool looks something like this:
> {code}
> Type: single-query
> Query start time: 1673373829119
> Protocol version: 5
> Generated timestamp:-9223372036854775808
> Generated nowInSeconds:1673373829
> Query: INSERT INTO ks1.t1 (id, v1, v2, v3) VALUES (?, ?, ?, ?)
> Values:
> 00 00 00 01
> 00 00 00 01
> -
> 00 00 00 01
> -
> 00 00 00 01
> -
> {code}
> - is not printed between the first and second value
> {code}
> Values:
> 00 00 00 01
> 00 00 00 01
> {code}
> We are normally very cautious about changing the output of the tooling but in
> this case I think this is a legit bug which should be fixed.
--
This message was sent by Atlassian Jira
(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-18113) fqltool dump results NPE when null value inserted using prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-18113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646794#comment-17646794
]
n.v.harikrishna commented on CASSANDRA-18113:
-
Prepared a patch for the fix: [https://github.com/apache/cassandra/pull/2050]
> fqltool dump results NPE when null value inserted using prepared query
> --
>
> Key: CASSANDRA-18113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18113
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Enable fullquerylog, prepare insert statement and bind it with a null value
> and execute it. Executing fqltool dump after insert will result into
> NullPointerException.
>
> Stept to reproduce:
> * Create cluster using ccm
> * Create a table something like:
> {code:java}
> CREATE TABLE ks1.t2 (
> id int PRIMARY KEY,
> value text
> ) ;
> {code}
> * Execute below code
> {code:java}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t2 (id, value) VALUES (?, ?)");
> cqlSession.execute(preparedStatement.bind(6, null));
> }
> {code}
> * Now running fqltool dump. It will run into NPE
>
>
> Stack trace:
> {code:java}
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at net.openhft.chronicle.bytes.BytesStore.wrap(BytesStore.java:76)
> at net.openhft.chronicle.bytes.Bytes.wrapForRead(Bytes.java:179)
> at
> org.apache.cassandra.fqltool.commands.Dump.appendValuesToStringBuilder(Dump.java:222)
> at org.apache.cassandra.fqltool.commands.Dump.dumpQuery(Dump.java:179)
> at org.apache.cassandra.fqltool.commands.Dump.lambda$dump$0(Dump.java:123)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.readDocument(StoreTailer.java:111)
> at org.apache.cassandra.fqltool.commands.Dump.dump(Dump.java:148)
> at org.apache.cassandra.fqltool.commands.Dump.run(Dump.java:68)
> at
> org.apache.cassandra.fqltool.FullQueryLogTool.main(FullQueryLogTool.java:65)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18113) fqltool dump results NPE when null value inserted using prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-18113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
n.v.harikrishna reassigned CASSANDRA-18113:
---
Assignee: n.v.harikrishna
> fqltool dump results NPE when null value inserted using prepared query
> --
>
> Key: CASSANDRA-18113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18113
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: n.v.harikrishna
>Assignee: n.v.harikrishna
>Priority: Normal
>
> Enable fullquerylog, prepare insert statement and bind it with a null value
> and execute it. Executing fqltool dump after insert will result into
> NullPointerException.
>
> Stept to reproduce:
> * Create cluster using ccm
> * Create a table something like:
> {code:java}
> CREATE TABLE ks1.t2 (
> id int PRIMARY KEY,
> value text
> ) ;
> {code}
> * Execute below code
> {code:java}
> try (CqlSession cqlSession = CqlSession.builder().build()) {
> PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
> ks1.t2 (id, value) VALUES (?, ?)");
> cqlSession.execute(preparedStatement.bind(6, null));
> }
> {code}
> * Now running fqltool dump. It will run into NPE
>
>
> Stack trace:
> {code:java}
> error: null
> -- StackTrace --
> java.lang.NullPointerException
> at net.openhft.chronicle.bytes.BytesStore.wrap(BytesStore.java:76)
> at net.openhft.chronicle.bytes.Bytes.wrapForRead(Bytes.java:179)
> at
> org.apache.cassandra.fqltool.commands.Dump.appendValuesToStringBuilder(Dump.java:222)
> at org.apache.cassandra.fqltool.commands.Dump.dumpQuery(Dump.java:179)
> at org.apache.cassandra.fqltool.commands.Dump.lambda$dump$0(Dump.java:123)
> at
> net.openhft.chronicle.queue.impl.single.StoreTailer.readDocument(StoreTailer.java:111)
> at org.apache.cassandra.fqltool.commands.Dump.dump(Dump.java:148)
> at org.apache.cassandra.fqltool.commands.Dump.run(Dump.java:68)
> at
> org.apache.cassandra.fqltool.FullQueryLogTool.main(FullQueryLogTool.java:65)
> {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-18113) fqltool dump results NPE when null value inserted using prepared query
n.v.harikrishna created CASSANDRA-18113:
---
Summary: fqltool dump results NPE when null value inserted using
prepared query
Key: CASSANDRA-18113
URL: https://issues.apache.org/jira/browse/CASSANDRA-18113
Project: Cassandra
Issue Type: Bug
Components: Tool/fql
Reporter: n.v.harikrishna
Enable fullquerylog, prepare insert statement and bind it with a null value and
execute it. Executing fqltool dump after insert will result into
NullPointerException.
Stept to reproduce:
* Create cluster using ccm
* Create a table something like:
{code:java}
CREATE TABLE ks1.t2 (
id int PRIMARY KEY,
value text
) ;
{code}
* Execute below code
{code:java}
try (CqlSession cqlSession = CqlSession.builder().build()) {
PreparedStatement preparedStatement = cqlSession.prepare("INSERT INTO
ks1.t2 (id, value) VALUES (?, ?)");
cqlSession.execute(preparedStatement.bind(6, null));
}
{code}
* Now running fqltool dump. It will run into NPE
Stack trace:
{code:java}
error: null
-- StackTrace --
java.lang.NullPointerException
at net.openhft.chronicle.bytes.BytesStore.wrap(BytesStore.java:76)
at net.openhft.chronicle.bytes.Bytes.wrapForRead(Bytes.java:179)
at
org.apache.cassandra.fqltool.commands.Dump.appendValuesToStringBuilder(Dump.java:222)
at org.apache.cassandra.fqltool.commands.Dump.dumpQuery(Dump.java:179)
at org.apache.cassandra.fqltool.commands.Dump.lambda$dump$0(Dump.java:123)
at
net.openhft.chronicle.queue.impl.single.StoreTailer.readDocument(StoreTailer.java:111)
at org.apache.cassandra.fqltool.commands.Dump.dump(Dump.java:148)
at org.apache.cassandra.fqltool.commands.Dump.run(Dump.java:68)
at
org.apache.cassandra.fqltool.FullQueryLogTool.main(FullQueryLogTool.java:65)
{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-17477) -dc option for repair, prevents incremental repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-17477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635994#comment-17635994
]
n.v.harikrishna commented on CASSANDRA-17477:
-
Sorry for taking so long to given an update.
As per the code here
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ActiveRepairService.java#L585]
{noformat}
/**
* we only want to set repairedAt for incremental repairs including all
replicas for a token range. For non-global
* incremental repairs, forced incremental repairs, and full repairs, the
UNREPAIRED_SSTABLE value will prevent
* sstables from being promoted to repaired or preserve the
repairedAt/pendingRepair values, respectively.
*/
static long getRepairedAt(RepairOption options, boolean force)
{
// we only want to set repairedAt for incremental repairs including all
replicas for a token range. For non-global incremental repairs, full repairs,
the UNREPAIRED_SSTABLE value will prevent
// sstables from being promoted to repaired or preserve the
repairedAt/pendingRepair values, respectively. For forced repairs, repairedAt
time is only set to UNREPAIRED_SSTABLE if we actually
// end up skipping replicas
if (options.isIncremental() && options.isGlobal() && !force)
{
return currentTimeMillis();
}
else
{
return ActiveRepairService.UNREPAIRED_SSTABLE;
}
}{noformat}
and RepairOption.isGlobal()
{noformat}
public boolean isGlobal()
{
return dataCenters.isEmpty() && hosts.isEmpty();
}
{noformat}
it is behaving as expected as the data centre is explicitly specified in the
first case.
> -dc option for repair, prevents incremental repairs
> ---
>
> Key: CASSANDRA-17477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17477
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Pedro Gordo
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> By default running `{*}nodetool repair{*}` should trigger incremental
> repairs, but this does not happen if you use the `{*}-dc{*}` flag, even
> though the repair summary says `{*}incremental: true{*}`.
> You can replicate the issue with the following commands:
> {code:bash}
> ccm create test-incremental-repairs -v 4.0.1 -n 3 -s
> ccm node1 cqlsh -e "CREATE KEYSPACE keyspace1 WITH replication = {'class':
> 'NetworkTopologyStrategy', 'datacenter1': 2 };"
> ccm stress write
> ccm node1 nodetool "repair keyspace1 standard1 -dc datacenter1"
> find ~/.ccm/test-incremental-repairs/*/data0/keyspace1/standard1* -name
> *Data.db -exec /bin/sstablemetadata {} \; | grep Repaired
> ccm node1 nodetool "repair keyspace1 standard1"
> find ~/.ccm/test-incremental-repairs/*/data0/keyspace1/standard1* -name
> *Data.db -exec /bin/sstablemetadata {} \; | grep Repaired
> {code}
> You'll notice that the output for the first `{*}find{*}` command will all be
> `{*}Repaired at: 0{*}`, but the second `{*}find{*}` command will give you
> results like `{*}Repaired at: 1648044754464 (03/23/2022 14:12:34){*}`.
> At the same time, both `{*}nodetool repair{*}` commands will output like the
> following:
> {code:bash}
> [2022-03-23 15:15:52,500] Starting repair command #2
> (20f12190-aabc-11ec-a3d4-e9e5a941ef6c), repairing keyspace keyspace1 with
> repair options (parallelism: parallel, primary range: false, incremental:
> true, job threads: 1, ColumnFamilies: [standard1], dataCenters:
> [datacenter1], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)
> {code}
> Indicating `{*}incremental: true{*}` for both of them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
