[jira] [Commented] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921157#comment-16921157
]
DeepakVohra commented on CASSANDRA-15296:
-
Thanks [~djoshi3] for fixing the bug.
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15092) Add a new Snitch for Alibaba Cloud Platform
[ https://issues.apache.org/jira/browse/CASSANDRA-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15092: --- Test and Documentation Plan: we add the unit test ,just run : ant test -Dtest.name=AlibabaCloudSnitchTest , and using this path many user can use cassandra in china using cassandra on aliyun . Status: Patch Available (was: Open) > Add a new Snitch for Alibaba Cloud Platform > --- > > Key: CASSANDRA-15092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15092 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core, Local/Config >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: trunk-15092.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Add snitch for Alibaba cloud platform, for we have saw cloud platform snitch > for aws and google cloud ,for we can ge alibaba ecs (Elastic Compute Service) > meta data from here : > https://help.aliyun.com/document_detail/108460.html?spm=a2c4g.11186623.6.675.36684f8bLQrIMY -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15092) Add a new Snitch for Alibaba Cloud Platform
[ https://issues.apache.org/jira/browse/CASSANDRA-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921134#comment-16921134 ] maxwellguo commented on CASSANDRA-15092: I modify the code and ut ,the newest PR is : https://github.com/apache/cassandra/pull/350 > Add a new Snitch for Alibaba Cloud Platform > --- > > Key: CASSANDRA-15092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15092 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core, Local/Config >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: trunk-15092.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Add snitch for Alibaba cloud platform, for we have saw cloud platform snitch > for aws and google cloud ,for we can ge alibaba ecs (Elastic Compute Service) > meta data from here : > https://help.aliyun.com/document_detail/108460.html?spm=a2c4g.11186623.6.675.36684f8bLQrIMY -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15092) Add a new Snitch for Alibaba Cloud Platform
[ https://issues.apache.org/jira/browse/CASSANDRA-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15092: --- Attachment: (was: trunk-15092-V1.txt) > Add a new Snitch for Alibaba Cloud Platform > --- > > Key: CASSANDRA-15092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15092 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core, Local/Config >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: trunk-15092.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Add snitch for Alibaba cloud platform, for we have saw cloud platform snitch > for aws and google cloud ,for we can ge alibaba ecs (Elastic Compute Service) > meta data from here : > https://help.aliyun.com/document_detail/108460.html?spm=a2c4g.11186623.6.675.36684f8bLQrIMY -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15092) Add a new Snitch for Alibaba Cloud Platform
[ https://issues.apache.org/jira/browse/CASSANDRA-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15092: --- Attachment: (was: trunk-15092.txt) > Add a new Snitch for Alibaba Cloud Platform > --- > > Key: CASSANDRA-15092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15092 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core, Local/Config >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: trunk-15092.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Add snitch for Alibaba cloud platform, for we have saw cloud platform snitch > for aws and google cloud ,for we can ge alibaba ecs (Elastic Compute Service) > meta data from here : > https://help.aliyun.com/document_detail/108460.html?spm=a2c4g.11186623.6.675.36684f8bLQrIMY -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15092) Add a new Snitch for Alibaba Cloud Platform
[ https://issues.apache.org/jira/browse/CASSANDRA-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15092: --- Attachment: trunk-15092.txt > Add a new Snitch for Alibaba Cloud Platform > --- > > Key: CASSANDRA-15092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15092 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core, Local/Config >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: trunk-15092.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Add snitch for Alibaba cloud platform, for we have saw cloud platform snitch > for aws and google cloud ,for we can ge alibaba ecs (Elastic Compute Service) > meta data from here : > https://help.aliyun.com/document_detail/108460.html?spm=a2c4g.11186623.6.675.36684f8bLQrIMY -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Test and Documentation Plan: for this is just filter the special charter ,so we do normal test with snapshot and snapshot with special charter in snapshot name and got the result we need Status: Patch Available (was: Open) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Bug Category: Parent values: Correctness(12982)Level 1 values: Unrecoverable Corruption / Loss(13161) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15296:
-
Bug Category: Parent values: Code(13163)
Status: Open (was: Triage Needed)
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15296:
-
Test and Documentation Plan: This is a documentation bug.
Status: Patch Available (was: Open)
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15296:
-
Complexity: Low Hanging Fruit
Discovered By: User Report
Reviewers: Dinesh Joshi
Severity: Low
Description:
The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range for
compression_level is indicated to be between -131072 and 2. The default value
is outside the range. Is it by design or a bug?
{code:java}
- ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
values between ``-131072`` and ``2``.
// Compressor Defaults
public static final int DEFAULT_COMPRESSION_LEVEL = 3;
{code}
https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
was:
The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range for
compression_level is indicated to be between -131072 and 2. The default value
is outside the range. Is it by design or a bug?
{code:java}
- ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
values between ``-131072`` and ``2``.
// Compressor Defaults
public static final int DEFAULT_COMPRESSION_LEVEL = 3;
{code}
https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Low
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920993#comment-16920993
]
Dinesh Joshi commented on CASSANDRA-15296:
--
Hi [~rha] and [~dvohra]. Thanks for reporting this issue. It looks like this
might be a typo in the documentation.
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Normal
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920991#comment-16920991
]
Romain Hardouin commented on CASSANDRA-15296:
-
Patch to fix the typo and add information about compression levels.
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Normal
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Hardouin updated CASSANDRA-15296:
Attachment: 15296-trunk.txt
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Priority: Normal
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Hardouin reassigned CASSANDRA-15296:
---
Assignee: Romain Hardouin
> ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Assignee: Romain Hardouin
>Priority: Normal
> Attachments: 15296-trunk.txt
>
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920975#comment-16920975
]
Romain Hardouin edited comment on CASSANDRA-15296 at 9/2/19 5:03 PM:
-
TLDR: the compression level interval is {{[-(2<<17), 22]}} i.e. {{[-131072,
22]}}
Looking at Z Standard C sources, the maximum is 22, not 2 (it's a typo):
{code:c}
#define ZSTD_MAX_CLEVEL 22
int ZSTD_maxCLevel(void) { return ZSTD_MAX_CLEVEL; }
int ZSTD_minCLevel(void) { return (int)-ZSTD_TARGETLENGTH_MAX; }
{code}
[https://github.com/facebook/zstd/blob/519834738228cc810b48a2d44ff295b845842af4/lib/compress/zstd_compress.c#L3823]
{{ZSTD_TARGETLENGTH_MAX}} is defined as:
{code:c}
#define ZSTD_TARGETLENGTH_MAXZSTD_BLOCKSIZE_MAX
{code}
{code:c}
#define ZSTD_BLOCKSIZELOG_MAX 17
#define ZSTD_BLOCKSIZE_MAX (1
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Priority: Normal
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15296) ZstdCompressor compression_level setting
[
https://issues.apache.org/jira/browse/CASSANDRA-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920975#comment-16920975
]
Romain Hardouin commented on CASSANDRA-15296:
-
TLDR: the compression level interval is {{[-(2<<17), 22]}} i.e. {{[-131072,
22]}}
Looking at Z Standard C sources, the maximum is indeed 22, not 2 (it's a typo):
{code:c}
#define ZSTD_MAX_CLEVEL 22
int ZSTD_maxCLevel(void) { return ZSTD_MAX_CLEVEL; }
int ZSTD_minCLevel(void) { return (int)-ZSTD_TARGETLENGTH_MAX; }
{code}
[https://github.com/facebook/zstd/blob/519834738228cc810b48a2d44ff295b845842af4/lib/compress/zstd_compress.c#L3823]
{{ZSTD_TARGETLENGTH_MAX}} is defined as:
{code:c}
#define ZSTD_TARGETLENGTH_MAXZSTD_BLOCKSIZE_MAX
{code}
{code:c}
#define ZSTD_BLOCKSIZELOG_MAX 17
#define ZSTD_BLOCKSIZE_MAX (1< ZstdCompressor compression_level setting
>
>
> Key: CASSANDRA-15296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15296
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies, Feature/Compression
>Reporter: DeepakVohra
>Priority: Normal
>
> The DEFAULT_COMPRESSION_LEVEL for ZstdCompressor is set to 3, but its range
> for compression_level is indicated to be between -131072 and 2. The default
> value is outside the range. Is it by design or a bug?
> {code:java}
> - ``compression_level`` is only applicable for ``ZstdCompressor`` and accepts
> values between ``-131072`` and ``2``.
> // Compressor Defaults
> public static final int DEFAULT_COMPRESSION_LEVEL = 3;
> {code}
> https://github.com/apache/cassandra/commit/dccf53061a61e7c632669c60cd94626e405518e9
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15299:
--
Authors: Aleksey Yeschenko, Sam Tunnicliffe (was: Aleksey Yeschenko)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15299:
--
Change Category: Semantic
Complexity: Normal
Status: Open (was: Triage Needed)
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
[
https://issues.apache.org/jira/browse/CASSANDRA-15299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-15299:
--
Fix Version/s: 4.0-beta
> CASSANDRA-13304 follow-up: improve checksumming and compression in protocol
> v5-beta
> ---
>
> Key: CASSANDRA-15299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Aleksey Yeschenko
>Assignee: Aleksey Yeschenko
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CASSANDRA-13304 made an important improvement to our native protocol: it
> introduced checksumming/CRC32 to request and response bodies. It’s an
> important step forward, but it doesn’t cover the entire stream. In
> parcicular, the message header is not covered by a checksum or a crc, which
> poses a correctness issue if, for example, {{streamId}} gets corrupted.
> Additionally, we aren’t quite using CRC32 correctly, in two ways:
> 1. We are calculating the CRC32 of the *decompressed* value instead of
> computing the CRC32 on the bytes written on the wire - losing the properties
> of the CRC32. In some cases, due to this sequencing, attempting to decompress
> a corrupt stream can cause a segfault by LZ4.
> 2. When using CRC32, the CRC32 value is written in the incorrect byte order,
> also losing some of the protections.
> See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
> explanation for the two points above.
> Separately, there are some long-standing issues with the protocol - since
> *way* before CASSANDRA-13304. Importantly, both checksumming and compression
> operate on individual message bodies rather than frames of multiple complete
> messages. In reality, this has several important additional downsides. To
> name a couple:
> # For compression, we are getting poor compression ratios for smaller
> messages - when operating on tiny sequences of bytes. In reality, for most
> small requests and responses we are discarding the compressed value as it’d
> be smaller than the uncompressed one - incurring both redundant allocations
> and compressions.
> # For checksumming and CRC32 we pay a high overhead price for small messages.
> 4 bytes extra is *a lot* for an empty write response, for example.
> To address the correctness issue of {{streamId}} not being covered by the
> checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
> should switch to a framing protocol with multiple messages in a single frame.
> I suggest we reuse the framing protocol recently implemented for internode
> messaging in CASSANDRA-15066 to the extent that its logic can be borrowed,
> and that we do it before native protocol v5 graduates from beta. See
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
> and
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15299) CASSANDRA-13304 follow-up: improve checksumming and compression in protocol v5-beta
Aleksey Yeschenko created CASSANDRA-15299:
-
Summary: CASSANDRA-13304 follow-up: improve checksumming and
compression in protocol v5-beta
Key: CASSANDRA-15299
URL: https://issues.apache.org/jira/browse/CASSANDRA-15299
Project: Cassandra
Issue Type: Improvement
Components: Messaging/Client
Reporter: Aleksey Yeschenko
Assignee: Aleksey Yeschenko
CASSANDRA-13304 made an important improvement to our native protocol: it
introduced checksumming/CRC32 to request and response bodies. It’s an important
step forward, but it doesn’t cover the entire stream. In parcicular, the
message header is not covered by a checksum or a crc, which poses a correctness
issue if, for example, {{streamId}} gets corrupted.
Additionally, we aren’t quite using CRC32 correctly, in two ways:
1. We are calculating the CRC32 of the *decompressed* value instead of
computing the CRC32 on the bytes written on the wire - losing the properties of
the CRC32. In some cases, due to this sequencing, attempting to decompress a
corrupt stream can cause a segfault by LZ4.
2. When using CRC32, the CRC32 value is written in the incorrect byte order,
also losing some of the protections.
See https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf for
explanation for the two points above.
Separately, there are some long-standing issues with the protocol - since *way*
before CASSANDRA-13304. Importantly, both checksumming and compression operate
on individual message bodies rather than frames of multiple complete messages.
In reality, this has several important additional downsides. To name a couple:
# For compression, we are getting poor compression ratios for smaller messages
- when operating on tiny sequences of bytes. In reality, for most small
requests and responses we are discarding the compressed value as it’d be
smaller than the uncompressed one - incurring both redundant allocations and
compressions.
# For checksumming and CRC32 we pay a high overhead price for small messages. 4
bytes extra is *a lot* for an empty write response, for example.
To address the correctness issue of {{streamId}} not being covered by the
checksum/CRC32 and the inefficiency in compression and checksumming/CRC32, we
should switch to a framing protocol with multiple messages in a single frame.
I suggest we reuse the framing protocol recently implemented for internode
messaging in CASSANDRA-15066 to the extent that its logic can be borrowed, and
that we do it before native protocol v5 graduates from beta. See
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderCrc.java
and
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/FrameDecoderLZ4.java.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15274) Multiple Corrupt datafiles across entire environment
[
https://issues.apache.org/jira/browse/CASSANDRA-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil O Conduin updated CASSANDRA-15274:
---
Impacts: (was: None)
> Multiple Corrupt datafiles across entire environment
> -
>
> Key: CASSANDRA-15274
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15274
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Phil O Conduin
>Priority: Normal
>
> Cassandra Version: 2.2.13
> PRE-PROD environment.
> * 2 datacenters.
> * 9 physical servers in each datacenter - (_Cisco UCS C220 M4 SFF_)
> * 4 Cassandra instances on each server (cass_a, cass_b, cass_c, cass_d)
> * 72 Cassandra instances across the 2 data centres, 36 in site A, 36 in site
> B.
> We also have 2 Reaper Nodes we use for repair. One reaper node in each
> datacenter each running with its own Cassandra back end in a cluster together.
> OS Details [Red Hat Linux]
> cass_a@x 0 10:53:01 ~ $ uname -a
> Linux x 3.10.0-957.5.1.el7.x86_64 #1 SMP Wed Dec 19 10:46:58 EST 2018 x86_64
> x86_64 x86_64 GNU/Linux
> cass_a@x 0 10:57:31 ~ $ cat /etc/*release
> NAME="Red Hat Enterprise Linux Server"
> VERSION="7.6 (Maipo)"
> ID="rhel"
> Storage Layout
> cass_a@xx 0 10:46:28 ~ $ df -h
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/vg01-lv_root 20G 2.2G 18G 11% /
> devtmpfs 63G 0 63G 0% /dev
> tmpfs 63G 0 63G 0% /dev/shm
> tmpfs 63G 4.1G 59G 7% /run
> tmpfs 63G 0 63G 0% /sys/fs/cgroup
> >> 4 cassandra instances
> /dev/sdd 1.5T 802G 688G 54% /data/ssd4
> /dev/sda 1.5T 798G 692G 54% /data/ssd1
> /dev/sdb 1.5T 681G 810G 46% /data/ssd2
> /dev/sdc 1.5T 558G 932G 38% /data/ssd3
> Cassandra load is about 200GB and the rest of the space is snapshots
> CPU
> cass_a@x 127 10:58:47 ~ $ lscpu | grep -E '^Thread|^Core|^Socket|^CPU\('
> CPU(s): 64
> Thread(s) per core: 2
> Core(s) per socket: 16
> Socket(s): 2
> *Description of problem:*
> During repair of the cluster, we are seeing multiple corruptions in the log
> files on a lot of instances. There seems to be no pattern to the corruption.
> It seems that the repair job is finding all the corrupted files for us. The
> repair will hang on the node where the corrupted file is found. To fix this
> we remove/rename the datafile and bounce the Cassandra instance. Our
> hardware/OS team have stated there is no problem on their side. I do not
> believe it the repair causing the corruption.
>
> So let me give you an example of a corrupted file and maybe someone might be
> able to work through it with me?
> When this corrupted file was reported in the log it looks like it was the
> repair that found it.
> $ journalctl -u cassmeta-cass_b.service --since "2019-08-07 22:25:00" --until
> "2019-08-07 22:45:00"
> Aug 07 22:30:33 cassandra[34611]: INFO 21:30:33 Writing
> Memtable-compactions_in_progress@830377457(0.008KiB serialized bytes, 1 ops,
> 0%/0% of on/off-heap limit)
> Aug 07 22:30:33 cassandra[34611]: ERROR 21:30:33 Failed creating a merkle
> tree for [repair #9587a200-b95a-11e9-8920-9f72868b8375 on KeyspaceMetadata/x,
> (-1476350953672479093,-1474461
> Aug 07 22:30:33 cassandra[34611]: ERROR 21:30:33 Exception in thread
> Thread[ValidationExecutor:825,1,main]
> Aug 07 22:30:33 cassandra[34611]: org.apache.cassandra.io.FSReadError:
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /x/ssd2/data/KeyspaceMetadata/x-1e453cb0
> Aug 07 22:30:33 cassandra[34611]: at
> org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:365)
> ~[apache-cassandra-2.2.13.jar:2.2.13]
> Aug 07 22:30:33 cassandra[34611]: at
> org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:361)
> ~[apache-cassandra-2.2.13.jar:2.2.13]
> Aug 07 22:30:33 cassandra[34611]: at
> org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:340)
> ~[apache-cassandra-2.2.13.jar:2.2.13]
> Aug 07 22:30:33 cassandra[34611]: at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:382)
> ~[apache-cassandra-2.2.13.jar:2.2.13]
> Aug 07 22:30:33 cassandra[34611]: at
> org.apache.cassandra.db.composites.AbstractCType$Serializer.deserialize(AbstractCType.java:366)
> ~[apache-cassandra-2.2.13.jar:2.2.13]
> Aug 07 22:30:33 cassandra[34611]: at
> org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:81)
> ~[apache-cassandra-2.2.13.jar:2.2.13]
> Aug 07 22:30:33
[jira] [Commented] (CASSANDRA-15274) Multiple Corrupt datafiles across entire environment
[
https://issues.apache.org/jira/browse/CASSANDRA-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920810#comment-16920810
]
Phil O Conduin commented on CASSANDRA-15274:
Hi,
We managed to remove the CRC check from the code and build. When we do a
sstable2json on a corrupt file we are not seeing an issue with CRC.
This time it is not CRC check, but exception during an attempt to decompress
the chunk, so I think we got the answer to our question - it is not just CRC
check problem.
Another area of investigation of this issue, we decided to create a script that
generated MD5 checksums against all sstable files. This script runs from cron
twice per day and logs checksums of all sstable files.
We capture the md5 and then compare it over the lifetime fo the file. We have
proved that the md5 checksum number is not changing. This would indicate a
possible bug in Cassandra at time of compacting/writing the file.
Taking the latest file for example:
*First reported in cassandra log Sep 01 08:39:48*
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
ERROR 07:39:48 Failed creating a merkle tree for [repair
#fb265fa0-cc8a-11e9-9296-5b5fb0093f98 on
KeyspaceMetadata/CF_ConversationIndex1,
(-2320162195562336336,-2318312110429971422]], /10.2.41.38 (see log for
details)}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
INFO 07:39:48 [repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98] Received merkle
tree for CF_ConversationIndex1 from /10.2.41.38}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
WARN 07:39:48 [repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98]
CF_ConversationIndex1 sync failed}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
INFO 07:39:48 [repair #fb265fa0-cc8a-11e9-9296-5b5fb0093f98] Requesting merkle
trees for CF_RecentIndex (to [/10.2.41.34, /10.2.41.48, /10.2.57.54,
/10.2.57.46, /10.2.57.12, /10.2.41.38])}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
ERROR 07:39:48 Exception in thread Thread[RepairJobTask:24,5,main]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
org.apache.cassandra.exceptions.RepairException: [repair
#fb265fa0-cc8a-11e9-9296-5b5fb0093f98 on
KeyspaceMetadata/CF_ConversationIndex1,
(-2320162195562336336,-2318312110429971422]] Validation failed in /10.2.41.38}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
org.apache.cassandra.repair.ValidationTask.treeReceived(ValidationTask.java:64)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
org.apache.cassandra.repair.RepairSession.validationComplete(RepairSession.java:178)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:478)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:174)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:67)
~[apache-cassandra-2.2.13.jar:2.2.13]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_172]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_172]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
~[na:1.8.0_172]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[na:1.8.0_172]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
java.lang.Thread.run(Thread.java:748) [na:1.8.0_172]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
ERROR 07:39:48 Exception in thread Thread[ValidationExecutor:53,1,main]}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]:
org.apache.cassandra.io.FSReadError:
org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
/data/ssd2/data/KeyspaceMetadata/CF_ConversationIndex1-1e77be609c7911e8ac12255de1fb512a/lb-26352-big-Data.db}}
{{Sep 01 08:39:48 sa-ref-met-009.btmx-ref.synchronoss.net cassandra[16223]: at
org.apache.cassandra.io.util.RandomAccessReader.readBytes(RandomAccessReader.java:365)
[jira] [Created] (CASSANDRA-15298) Cassandra node cannot be restored using documented backup method
Charlemange Lasse created CASSANDRA-15298:
-
Summary: Cassandra node cannot be restored using documented backup
method
Key: CASSANDRA-15298
URL: https://issues.apache.org/jira/browse/CASSANDRA-15298
Project: Cassandra
Issue Type: Bug
Reporter: Charlemange Lasse
I have a single cassandra 3.11.4 node. It contains various tables and UDFs. The
[documentation describes a method to backup this
node|https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/operations/opsBackupTakesSnapshot.html]:
* use "DESCRIBE SCHEMA" in cqlsh to get the schema
* create a snapshot using nodetool
* copy the snapshot + schema to a new (completely disconnected) node
* load schema into new node
* load sstables again using nodetool
But this is a complete bogus method. It will result in errors like:
{noformat}
java.lang.RuntimeException: Unknown column deleted_column during
deserialization {noformat}
And all data in this column is now lost.
Problem is that the "DESCRIBE SCHEMA" CQL doesn't add the stuff correctly for
already deleted (but still existing columns) to the schema. It looks for
example like:
{noformat}
CREATE TABLE mykeyspace.testcf (
primary_uuid uuid,
secondary_uuid uuid,
name text,
PRIMARY KEY (main_uuid, secondary_uuid)
) WITH CLUSTERING ORDER BY (secondary_uuid ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
{noformat}
But it must actually look like:
{noformat}
CREATE TABLE IF NOT EXISTS mykeyspace.testcf (
primary_uuid uuid,
secondary_uuid uuid,
name text,
deleted_column boolean,
PRIMARY KEY (main_uuid, secondary_uuid)
WITH ID = a1afdd4d-b61e-4f2a-b806-57c296be3948
AND CLUSTERING ORDER BY (ap_uuid ASC)
AND bloom_filter_fp_chance = 0.01
AND dclocal_read_repair_chance = 0.1
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND min_index_interval = 128
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE'
AND comment = ''
AND caching = { 'keys': 'ALL', 'rows_per_partition': 'NONE' }
AND compaction = { 'max_threshold': '32', 'min_threshold': '4',
'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy' }
AND compression = { 'chunk_length_in_kb': '64', 'class':
'org.apache.cassandra.io.compress.LZ4Compressor' }
AND cdc = false
AND extensions = { };
ALTER TABLE mykeyspace.testcf DROP deleted_column USING TIMESTAMP
1563978151561000;
{noformat}
This was taken from the snapshot's (column family specific) schema.cql. Which
of course is not compatible with the main schema because it will only create
the tables when they don't exist (which they are because the main "DESCRIBE
SCHEMA" file already creates them) and is missing all other kind of stuff like
UDFs.
It is currently not possible (using the builtin mechanisms from cassandra
3.11.4) to migrate a keyspace from one separated server to another separated
server.
This behavior also breaks various backup systems which try to store cassandra
cluster information to an offline storage.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15216) Cross node message creation times are disabled by default
[
https://issues.apache.org/jira/browse/CASSANDRA-15216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920755#comment-16920755
]
Benedict commented on CASSANDRA-15216:
--
Thanks for the offer. This is a two word change, though (from {{false}} to
{{true}}, in {{cassandra.yaml}} and {{Config}}), and probably too trivial to
even bother with submission and review; it can probably be ninja'd in. The
only requirement is a brief discussion to confirm nobody disagrees this should
happen.
> Cross node message creation times are disabled by default
> -
>
> Key: CASSANDRA-15216
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15216
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Benedict
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> This can cause a lot of wasted work for messages that have timed out on the
> coordinator. We should generally assume that our users have setup NTP on
> their clusters, and that clocks are modestly in sync, since it’s a
> requirement for general correctness of last write wins.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15228) CommitLogReplayer should replay past final sync marker
[ https://issues.apache.org/jira/browse/CASSANDRA-15228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920747#comment-16920747 ] Benedict edited comment on CASSANDRA-15228 at 9/2/19 10:11 AM: --- \[This comment refers to prior goal of avoiding writing the sync markers\] It had been a long time since I looked at the commit log code, and taking a look now, this has obviously become tightly interwoven with other extended behaviours (encryption and compression) that I would prefer not to unpick anytime soon. This isn't the simplifying change I had hoped it would be. I think it would be preferable to defer any refactoring until we can address CASSANDRA-9834. We can instead, at any time during 4.0 (or later if we choose) modify the replayer to simply ignore the lack of a final sync marker, and to attempt to replay the contents in-between, to restore earlier persistence behaviour without any user-visible file format changes. was (Author: benedict): \[This comment refers to prior goal of avoiding writing the sync markers]\ It had been a long time since I looked at the commit log code, and taking a look now, this has obviously become tightly interwoven with other extended behaviours (encryption and compression) that I would prefer not to unpick anytime soon. This isn't the simplifying change I had hoped it would be. I think it would be preferable to defer any refactoring until we can address CASSANDRA-9834. We can instead, at any time during 4.0 (or later if we choose) modify the replayer to simply ignore the lack of a final sync marker, and to attempt to replay the contents in-between, to restore earlier persistence behaviour without any user-visible file format changes. > CommitLogReplayer should replay past final sync marker > -- > > Key: CASSANDRA-15228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15228 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Benedict >Priority: Normal > Fix For: 4.0.x > > > Under default commit log configuration, the sync markers have no purpose, > only serving to reduce persistence by preventing replay of any mutations > serialised between syncs. Refactoring the commit log to prevent this would > be painful, given their utility for encrypted and compressed segments, so we > should instead ignore the lack of a final sync marker when replaying a raw > commit log segment, and attempt to replay any mutations we encounter after > the last sync marker. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15228) CommitLogReplayer should replay past final sync marker
[ https://issues.apache.org/jira/browse/CASSANDRA-15228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15228: - Description: Under default commit log configuration, the sync markers have no purpose, only serving to reduce persistence by preventing replay of any mutations serialised between syncs. Refactoring the commit log to prevent this would be painful, given their utility for encrypted and compressed segments, so we should instead ignore the lack of a final sync marker when replaying a raw commit log segment, and attempt to replay any mutations we encounter after the last sync marker. (was: The sync markers existed to permit file re-use. Since we no longer re-use files, they no longer provide any value. However, they _can_ corrupt the commit log for replay in the event of a process crash. Before we release 4.0, we should ideally remove the sync markers entirely. ) > CommitLogReplayer should replay past final sync marker > -- > > Key: CASSANDRA-15228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15228 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Benedict >Priority: Normal > Fix For: 4.0.x > > > Under default commit log configuration, the sync markers have no purpose, > only serving to reduce persistence by preventing replay of any mutations > serialised between syncs. Refactoring the commit log to prevent this would > be painful, given their utility for encrypted and compressed segments, so we > should instead ignore the lack of a final sync marker when replaying a raw > commit log segment, and attempt to replay any mutations we encounter after > the last sync marker. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15228) CommitLogReplayer should replay past final sync marker
[ https://issues.apache.org/jira/browse/CASSANDRA-15228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920747#comment-16920747 ] Benedict edited comment on CASSANDRA-15228 at 9/2/19 10:10 AM: --- \[This comment refers to prior goal of avoiding writing the sync markers]\ It had been a long time since I looked at the commit log code, and taking a look now, this has obviously become tightly interwoven with other extended behaviours (encryption and compression) that I would prefer not to unpick anytime soon. This isn't the simplifying change I had hoped it would be. I think it would be preferable to defer any refactoring until we can address CASSANDRA-9834. We can instead, at any time during 4.0 (or later if we choose) modify the replayer to simply ignore the lack of a final sync marker, and to attempt to replay the contents in-between, to restore earlier persistence behaviour without any user-visible file format changes. was (Author: benedict): It had been a long time since I looked at the commit log code, and taking a look now, this has obviously become tightly interwoven with other extended behaviours (encryption and compression) that I would prefer not to unpick anytime soon. This isn't the simplifying change I had hoped it would be. I think it would be preferable to defer any refactoring until we can address CASSANDRA-9834. We can instead, at any time during 4.0 (or later if we choose) modify the replayer to simply ignore the lack of a final sync marker, and to attempt to replay the contents in-between, to restore earlier persistence behaviour without any user-visible file format changes. > CommitLogReplayer should replay past final sync marker > -- > > Key: CASSANDRA-15228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15228 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Benedict >Priority: Normal > Fix For: 4.0.x > > > Under default commit log configuration, the sync markers have no purpose, > only serving to reduce persistence by preventing replay of any mutations > serialised between syncs. Refactoring the commit log to prevent this would > be painful, given their utility for encrypted and compressed segments, so we > should instead ignore the lack of a final sync marker when replaying a raw > commit log segment, and attempt to replay any mutations we encounter after > the last sync marker. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15228) CommitLogReplayer should replay past final sync marker
[ https://issues.apache.org/jira/browse/CASSANDRA-15228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15228: - Fix Version/s: (was: 4.0-alpha) (was: 4.0) 4.0.x > CommitLogReplayer should replay past final sync marker > -- > > Key: CASSANDRA-15228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15228 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Benedict >Priority: Normal > Fix For: 4.0.x > > > The sync markers existed to permit file re-use. Since we no longer re-use > files, they no longer provide any value. However, they _can_ corrupt the > commit log for replay in the event of a process crash. Before we release > 4.0, we should ideally remove the sync markers entirely. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15228) CommitLogReplayer should replay past final sync marker
[ https://issues.apache.org/jira/browse/CASSANDRA-15228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15228: - Summary: CommitLogReplayer should replay past final sync marker (was: Commit Log should not use sync markers) > CommitLogReplayer should replay past final sync marker > -- > > Key: CASSANDRA-15228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15228 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Benedict >Priority: Normal > Fix For: 4.0, 4.0-alpha > > > The sync markers existed to permit file re-use. Since we no longer re-use > files, they no longer provide any value. However, they _can_ corrupt the > commit log for replay in the event of a process crash. Before we release > 4.0, we should ideally remove the sync markers entirely. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15228) Commit Log should not use sync markers
[ https://issues.apache.org/jira/browse/CASSANDRA-15228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920747#comment-16920747 ] Benedict commented on CASSANDRA-15228: -- It had been a long time since I looked at the commit log code, and taking a look now, this has obviously become tightly interwoven with other extended behaviours (encryption and compression) that I would prefer not to unpick anytime soon. This isn't the simplifying change I had hoped it would be. I think it would be preferable to defer any refactoring until we can address CASSANDRA-9834. We can instead, at any time during 4.0 (or later if we choose) modify the replayer to simply ignore the lack of a final sync marker, and to attempt to replay the contents in-between, to restore earlier persistence behaviour without any user-visible file format changes. > Commit Log should not use sync markers > -- > > Key: CASSANDRA-15228 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15228 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Benedict >Priority: Normal > Fix For: 4.0, 4.0-alpha > > > The sync markers existed to permit file re-use. Since we no longer re-use > files, they no longer provide any value. However, they _can_ corrupt the > commit log for replay in the event of a process crash. Before we release > 4.0, we should ideally remove the sync markers entirely. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15092) Add a new Snitch for Alibaba Cloud Platform
[ https://issues.apache.org/jira/browse/CASSANDRA-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-15092: Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add a new Snitch for Alibaba Cloud Platform > --- > > Key: CASSANDRA-15092 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15092 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core, Local/Config >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: trunk-15092-V1.txt, trunk-15092.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Add snitch for Alibaba cloud platform, for we have saw cloud platform snitch > for aws and google cloud ,for we can ge alibaba ecs (Elastic Compute Service) > meta data from here : > https://help.aliyun.com/document_detail/108460.html?spm=a2c4g.11186623.6.675.36684f8bLQrIMY -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Fix Version/s: 4.x > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 10m > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-15297: --- Labels: pull-request-available (was: ) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Description: we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link !snapshot-p-s.jpg! !listsnapshots-p-s.jpg! 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link !snapshot-listsnapshot-.jpg! the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. was: we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link !snapshot-p-s.jpg! !listsnapshots-p-s.jpg! 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link !snapshots-listsnapshot-.jpg.jpg! the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: snapshot-listsnapshot-.jpg > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: snapshots-listsnapshot-.jpg.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, snapshot-p-s.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Description: we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link !snapshot-p-s.jpg! !listsnapshots-p-s.jpg! 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link !snapshots-listsnapshot-.jpg.jpg! the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. was: we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link !snapshot-p-s.jpg! !snapshot-p-s.jpg! 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link !snapshots-listsnapshot-.jpg.jpg! the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, snapshot-p-s.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: listsnapshots-p-s.jpg snapshots-listsnapshot-.jpg.jpg snapshot-p-s.jpg > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, snapshot-p-s.jpg, > snapshots-listsnapshot-.jpg.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !snapshot-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: snapshots-listsnapshot-.jpg.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !snapshot-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: listsnapshots-p-s.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !snapshot-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: snapshot-p-s.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !snapshot-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920709#comment-16920709 ] maxwellguo commented on CASSANDRA-15297: after we fix the bug the resultt should be like this : !after-fix.jpg! > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, snapshot-p-s.jpg, > snapshots-listsnapshot-.jpg.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: after-fix.jpg > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, snapshot-p-s.jpg, > snapshots-listsnapshot-.jpg.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Description: we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link !snapshot-p-s.jpg! !snapshot-p-s.jpg! 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link !snapshots-listsnapshot-.jpg.jpg! the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. was: we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: after-fix.jpg, listsnapshots-p-s.jpg, snapshot-p-s.jpg, > snapshots-listsnapshot-.jpg.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !snapshot-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshots-listsnapshot-.jpg.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: snapshot-p-s.jpg listsnapshots-p-s.jpg snapshots-listsnapshot-.jpg.jpg > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Attachments: listsnapshots-p-s.jpg, snapshot-p-s.jpg, > snapshots-listsnapshot-.jpg.jpg > > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: 屏幕快照 2019-09-02 16.51.33.png) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: 2.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: 3.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: 1.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: 屏幕快照 2019-09-02 16.51.33.png > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maxwellguo updated CASSANDRA-15297: --- Attachment: (was: 1.jpg) > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
maxwellguo created CASSANDRA-15297: -- Summary: nodetool can not create snapshot with snapshot name that have special character Key: CASSANDRA-15297 URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 Project: Cassandra Issue Type: Bug Components: Tool/nodetool Reporter: maxwellguo Assignee: maxwellguo Attachments: 1.jpg, 1.jpg, 2.jpg, 3.jpg we make snapshot through "nodetool snapshot -t snapshotname " , when snapshotname contains special characters like "/", the make snapshot process successfully , but the result can be different ,when we check the data file directory or use "nodetool listsnapshots". here is some case : 1. nodetool snapshot -t "p/s" the listsnapshot resturns snapshot p for all table but actually the snapshot name is "p/s"; also the data directory is like the format : datapath/snapshots/p/s/snapshot-datafile-link 2. nodetool snapshot -t "/" the listsnapshot resturns "there is not snapshot"; but the make snapshot process return successfully and the data directory is like the format : datapath/snapshots/snapshot-datafile-link the Attachements are the result under our environment. so for me , we suggest that the snapshot name should not contains special character. just throw exception and told the user not to use special character. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
