[jira] [Updated] (CASSANDRA-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
[
https://issues.apache.org/jira/browse/CASSANDRA-18968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18968:
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Low Hanging Fruit
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> StartupClusterConnectivityChecker fails on upgrade from 3.X
> ---
>
> Key: CASSANDRA-18968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Priority: Normal
>
> Starting up a new 4.X node on a 3.x cluster throws the following warning:
> {noformat}
> WARN [main] 2023-10-27 15:58:22,234
> StartupClusterConnectivityChecker.java:183 - Timed out after 10002
> milliseconds, was waiting for remaining peers to connect: {dc1=[X.Y.Z.W,
> A.B.C.D]}
> {noformat}
> I think this is because the PING messages used by the startup check are not
> available on 3.X.
> To provide a smoother upgrade experience we should probably disable this
> check on a mixed version clusters, or skip peers on versions < 4.x when doing
> the connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18968) StartupClusterConnectivityChecker fails on upgrade from 3.X
Paulo Motta created CASSANDRA-18968:
---
Summary: StartupClusterConnectivityChecker fails on upgrade from
3.X
Key: CASSANDRA-18968
URL: https://issues.apache.org/jira/browse/CASSANDRA-18968
Project: Cassandra
Issue Type: Bug
Components: Local/Startup and Shutdown
Reporter: Paulo Motta
Starting up a new 4.X node on a 3.x cluster throws the following warning:
{noformat}
WARN [main] 2023-10-27 15:58:22,234 StartupClusterConnectivityChecker.java:183
- Timed out after 10002 milliseconds, was waiting for remaining peers to
connect: {dc1=[X.Y.Z.W, A.B.C.D]}
{noformat}
I think this is because the PING messages used by the startup check are not
available on 3.X.
To provide a smoother upgrade experience we should probably disable this check
on a mixed version clusters, or skip peers on versions < 4.x when doing the
connectivity check.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18868) Document grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18868:
Description:
Update https://cassandra.apache.org/doc/4.1/cassandra/cql/security.html to
include the new DCL added by CASSANDRA-17027.
{code:sql}
GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
{code}
was:
Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
include the new DCL added by CASSANDRA-17027.
{code:sql}
GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
{code}
> Document grant permission for all tables in a keyspace
> --
>
> Key: CASSANDRA-18868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18868
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> Update https://cassandra.apache.org/doc/4.1/cassandra/cql/security.html to
> include the new DCL added by CASSANDRA-17027.
> {code:sql}
> GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18869) Document multiple GRANT or REVOKE permissions in a single statement
[
https://issues.apache.org/jira/browse/CASSANDRA-18869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18869:
Description:
Update https://cassandra.apache.org/doc/4.1/cassandra/cql/security.html to
include the new DCL added by CASSANDRA-17027.
{code:sql}
GRANT MODIFY, SELECT ON KEYSPACE field TO manager;
{code}
was:
Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
include the new DCL added by CASSANDRA-17027.
{code:sql}
GRANT MODIFY, SELECT ON KEYSPACE field TO manager;
{code}
> Document multiple GRANT or REVOKE permissions in a single statement
> ---
>
> Key: CASSANDRA-18869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18869
> Project: Cassandra
> Issue Type: Task
>Reporter: Paulo Motta
>Priority: Normal
>
> Update https://cassandra.apache.org/doc/4.1/cassandra/cql/security.html to
> include the new DCL added by CASSANDRA-17027.
> {code:sql}
> GRANT MODIFY, SELECT ON KEYSPACE field TO manager;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18869) Document multiple GRANT or REVOKE permissions in a single statement
Paulo Motta created CASSANDRA-18869:
---
Summary: Document multiple GRANT or REVOKE permissions in a single
statement
Key: CASSANDRA-18869
URL: https://issues.apache.org/jira/browse/CASSANDRA-18869
Project: Cassandra
Issue Type: Task
Reporter: Paulo Motta
Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
include the new DCL added by CASSANDRA-17027.
{code:sql}
GRANT MODIFY, SELECT ON KEYSPACE field TO manager;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18868) Document grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18868:
Component/s: Documentation/Website
> Document grant permission for all tables in a keyspace
> --
>
> Key: CASSANDRA-18868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18868
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Paulo Motta
>Priority: Normal
>
> Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
> include the new DCL added by CASSANDRA-17027.
> {code:sql}
> GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18868) Document grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18868:
Complexity: Low Hanging Fruit
> Document grant permission for all tables in a keyspace
> --
>
> Key: CASSANDRA-18868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18868
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
> include the new DCL added by CASSANDRA-17027.
> {code:sql}
> GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18868) Document grant permission for all tables in a keyspace
Paulo Motta created CASSANDRA-18868:
---
Summary: Document grant permission for all tables in a keyspace
Key: CASSANDRA-18868
URL: https://issues.apache.org/jira/browse/CASSANDRA-18868
Project: Cassandra
Issue Type: Task
Reporter: Paulo Motta
Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
include the new DCL added by CASSANDRA-17027.
{code:sql}
GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18868) Document grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18868:
Labels: lhf (was: )
> Document grant permission for all tables in a keyspace
> --
>
> Key: CASSANDRA-18868
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18868
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> Update https://cassandra.apache.org/doc/4.0/cassandra/cql/security.html to
> include the new DCL added by CASSANDRA-17027.
> {code:sql}
> GRANT ALTER ON ALL TABLES IN KEYSPACE ks TO user;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18867) Document GROUP BY time interval feature
[
https://issues.apache.org/jira/browse/CASSANDRA-18867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18867:
Complexity: Low Hanging Fruit
Labels: lhf (was: )
> Document GROUP BY time interval feature
> ---
>
> Key: CASSANDRA-18867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18867
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> It looks like the aggregation by time range feature added by CASSANDRA-11871
> was not added to the documentation.
> Example:
> {code:sql}
> SELECT pk, date, floor(time, 5m), min(v), max(v), count(v) FROM table GROUP
> BY pk, date, floor(time, 5m)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18867) Document GROUP BY time interval feature
Paulo Motta created CASSANDRA-18867:
---
Summary: Document GROUP BY time interval feature
Key: CASSANDRA-18867
URL: https://issues.apache.org/jira/browse/CASSANDRA-18867
Project: Cassandra
Issue Type: Task
Components: Documentation/Website
Reporter: Paulo Motta
It looks like the aggregation by time range feature added by CASSANDRA-11871
was not added to the documentation.
Example:
{code:sql}
SELECT pk, date, floor(time, 5m), min(v), max(v), count(v) FROM table GROUP BY
pk, date, floor(time, 5m)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18482) Test Failure: HintsDisabledTest.testHintedHandoffDisabled
[
https://issues.apache.org/jira/browse/CASSANDRA-18482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716879#comment-17716879
]
Paulo Motta commented on CASSANDRA-18482:
-
+1, thanks for fixing this
> Test Failure: HintsDisabledTest.testHintedHandoffDisabled
> -
>
> Key: CASSANDRA-18482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18482
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1.x, 5.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test throws timeout exception before the CL.ONE request completes. Need to
> increase the timeout and make sure hints have had the opportunity to deliver.
>
> {{code}}
> Error Message
> Operation timed out - received only 0 responses.
> Stacktrace
> org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out -
> received only 0 responses.
> at
> org.apache.cassandra.service.AbstractWriteResponseHandler.throwTimeout(AbstractWriteResponseHandler.java:152)
> at
> org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:130)
> at
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:901)
> at
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:1151)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:519)
> at
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:493)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103)
> at
> org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {{code}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18371) Snapshots with dots in their name are not returned in listsnapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-18371: Reviewers: Paulo Motta, Paulo Motta (was: Paulo Motta) Paulo Motta, Paulo Motta (was: Paulo Motta) Status: Review In Progress (was: Patch Available) > Snapshots with dots in their name are not returned in listsnapshots > --- > > Key: CASSANDRA-18371 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18371 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18371) Snapshots with dots in their name are not returned in listsnapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706033#comment-17706033 ] Paulo Motta commented on CASSANDRA-18371: - LGTM > Snapshots with dots in their name are not returned in listsnapshots > --- > > Key: CASSANDRA-18371 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18371 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18371) Snapshots with dots in their name are not returned in listsnapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-18371: Reviewers: Paulo Motta > Snapshots with dots in their name are not returned in listsnapshots > --- > > Key: CASSANDRA-18371 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18371 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18371) Snapshots with dots in their name are not returned in listsnapshots
[ https://issues.apache.org/jira/browse/CASSANDRA-18371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-18371: Status: Ready to Commit (was: Review In Progress) > Snapshots with dots in their name are not returned in listsnapshots > --- > > Key: CASSANDRA-18371 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18371 > Project: Cassandra > Issue Type: Bug > Components: Local/Snapshots >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704701#comment-17704701 ] Paulo Motta commented on CASSANDRA-16325: - Now that CASSANDRA-18304 is committed I rebased this patch and resubmitted CI: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2392/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2392/pipeline] Prepared patch is on [this branch|https://github.com/pauloricardomg/cassandra/tree/feature/CASSANDRA-16325]. Also includes a [commit|https://github.com/pauloricardomg/cassandra/commit/43e9f7c7932dbdb6b654be59fecd8300ccdbf2b] to log node configuration on dtests, which allowed to verify that the configuration is being properly set. > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 5.0 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18304:
Fix Version/s: 4.1.2
(was: 5.x)
(was: 4.1.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/7c2f97cd29486196b50c65a093e92b0fcd9789d9
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704688#comment-17704688
]
Paulo Motta commented on CASSANDRA-18304:
-
Thanks for the review. Finally got a 4.1 CI to not fail:
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2391/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2391/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2369/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2369/pipeline]
will commit shortly
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18359:
Reviewers: Paulo Motta, Paulo Motta
Paulo Motta, Paulo Motta (was: Paulo Motta)
Status: Review In Progress (was: Patch Available)
> NullPointerException on SnapshotLoader.loadSnapshots
>
>
> Key: CASSANDRA-18359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Node startup fail with on 4.1.1:
> {noformat}
> INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
> migration coordinator and scheduling pulling schema versions every PT1M
> ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
> at
> org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18359:
Status: Ready to Commit (was: Review In Progress)
> NullPointerException on SnapshotLoader.loadSnapshots
>
>
> Key: CASSANDRA-18359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Node startup fail with on 4.1.1:
> {noformat}
> INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
> migration coordinator and scheduling pulling schema versions every PT1M
> ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
> at
> org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18359:
Test and Documentation Plan: changes.txt
Status: Patch Available (was: In Progress)
> NullPointerException on SnapshotLoader.loadSnapshots
>
>
> Key: CASSANDRA-18359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Node startup fail with on 4.1.1:
> {noformat}
> INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
> migration coordinator and scheduling pulling schema versions every PT1M
> ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
> at
> org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704684#comment-17704684
]
Paulo Motta commented on CASSANDRA-18359:
-
bq. PR is here [https://github.com/apache/cassandra/pull/2243]
+1
bq. I think that we should make setting one of dirs to "/" illegal. It does
not make sense. If we were to scan all dirs in / for snapshots, we would
basically have to traverse whole filesystem. That is dangerous, time consuming,
error prone on ownership etc etc.
I think settings data dirs to "/" is too esoteric to worry about.
> NullPointerException on SnapshotLoader.loadSnapshots
>
>
> Key: CASSANDRA-18359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Node startup fail with on 4.1.1:
> {noformat}
> INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
> migration coordinator and scheduling pulling schema versions every PT1M
> ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
> at
> org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704372#comment-17704372
]
Paulo Motta commented on CASSANDRA-18359:
-
Issue seems to be on [this
check|https://github.com/apache/cassandra/blob/cassandra-4.1.1/src/java/org/apache/cassandra/service/snapshot/SnapshotLoader.java#L106]
as pointed out by [~brandon.williams]
[~stefan.miklosovic] I suspect this would only happen when
{{{}data_file_directories: /{}}}, which is an odd choice but still valid. We
probably need to add a null check here.
I wonder if {{if
(subdir.getParent().getFileName().toString().equals(SNAPSHOT_SUBDIR))}} could
run into permissioning issues if the user does not have permissions to access
the parent directory of {}data_file_directories{}}}{}}}
> NullPointerException on SnapshotLoader.loadSnapshots
>
>
> Key: CASSANDRA-18359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Priority: Normal
>
> Node startup fail with on 4.1.1:
> {noformat}
> INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
> migration coordinator and scheduling pulling schema versions every PT1M
> ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
> at
> org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18359:
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> NullPointerException on SnapshotLoader.loadSnapshots
>
>
> Key: CASSANDRA-18359
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Paulo Motta
>Priority: Normal
>
> Node startup fail with on 4.1.1:
> {noformat}
> INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
> migration coordinator and scheduling pulling schema versions every PT1M
> ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
> encountered during startup
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
> at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
> at
> org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
> at
> org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
> at
> org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18359) NullPointerException on SnapshotLoader.loadSnapshots
Paulo Motta created CASSANDRA-18359:
---
Summary: NullPointerException on SnapshotLoader.loadSnapshots
Key: CASSANDRA-18359
URL: https://issues.apache.org/jira/browse/CASSANDRA-18359
Project: Cassandra
Issue Type: Bug
Components: Local/Snapshots
Reporter: Paulo Motta
Node startup fail with on 4.1.1:
{noformat}
INFO [main] 2023-03-23 18:13:13,585 MigrationCoordinator.java:257 - Starting
migration coordinator and scheduling pulling schema versions every PT1M
ERROR [main] 2023-03-23 18:13:13,592 CassandraDaemon.java:898 - Exception
encountered during startup
java.lang.NullPointerException: null
at
org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:106)
at
org.apache.cassandra.service.snapshot.SnapshotLoader$Visitor.preVisitDirectory(SnapshotLoader.java:77)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2732)
at
org.apache.cassandra.service.snapshot.SnapshotLoader.loadSnapshots(SnapshotLoader.java:162)
at
org.apache.cassandra.service.snapshot.SnapshotManager.loadSnapshots(SnapshotManager.java:114)
at
org.apache.cassandra.service.snapshot.SnapshotManager.start(SnapshotManager.java:88)
at
org.apache.cassandra.service.StorageService.startSnapshotManager(StorageService.java:1050)
at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:1043)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:842)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:775)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:425)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:752)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:876)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16356) Add size histogram for Cassandra read operations
[ https://issues.apache.org/jira/browse/CASSANDRA-16356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16356: Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Add size histogram for Cassandra read operations > > > Key: CASSANDRA-16356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16356 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Adelina Vidovici >Priority: Normal > > Similar to MutationSizeHistogram which exists for write operations, there is > a need for having metrics also regarding the size of the read operations. > More details for client documentation metrics can be found here: > https://cassandra.apache.org/doc/latest/operating/metrics.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16356) Add size histogram for Cassandra read operations
[ https://issues.apache.org/jira/browse/CASSANDRA-16356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16356: Labels: lhf (was: ) > Add size histogram for Cassandra read operations > > > Key: CASSANDRA-16356 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16356 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Adelina Vidovici >Priority: Normal > Labels: lhf > > Similar to MutationSizeHistogram which exists for write operations, there is > a need for having metrics also regarding the size of the read operations. > More details for client documentation metrics can be found here: > https://cassandra.apache.org/doc/latest/operating/metrics.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18102) Add a virtual table to list snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703206#comment-17703206
]
Paulo Motta commented on CASSANDRA-18102:
-
sounds good, thanks!
> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
> class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>
> tag | keyspace_name | table_name | table_id | is_ephemeral | created_at |
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info |
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z |
> null |
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702752#comment-17702752
]
Paulo Motta edited comment on CASSANDRA-18304 at 3/20/23 5:33 PM:
--
CI failed due to unused imports
Resubmitted after fixing
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2368/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2368/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2369/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2369/pipeline]
was (Author: paulo):
CI failed due to unused imports
Resubmitted after fixing
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2365/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2365/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2366/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2366/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18102) Add a virtual table to list snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702753#comment-17702753
]
Paulo Motta commented on CASSANDRA-18102:
-
bq. I was discussing with Andres that we might add CQL functions taking longs
and returning whatever size unit one wants. Like sizeof('true_size', 'MiB')
would return it in MiB.
This would be nice, is there a ticket for it yet?
bq. The build seems fairly OK.
+1, let's wait 24 hours to see if there's any feedback in the discuss thread
and we can merge this tomorrow
> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
> class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>
> tag | keyspace_name | table_name | table_id | is_ephemeral | created_at |
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info |
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z |
> null |
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702752#comment-17702752
]
Paulo Motta commented on CASSANDRA-18304:
-
CI failed due to unused imports
Resubmitted after fixing
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2365/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2365/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2366/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2366/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18102) Add a virtual table to list snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702326#comment-17702326
]
Paulo Motta commented on CASSANDRA-18102:
-
{quote}I reworked the whole implementation a little bit. We need to retrieve
these snapshots from snapshot loader.
{quote}
Nice, this looks cleaner.
One issue I found is that it was not possible to filter snapshots by size
because they're in human readable string format, so I updated the
{{size_on_disk}} and {{true_size}} to be long instead, to allow filtering by
snapshot size:
{noformat}
cqlsh> SELECT * from system_views.snapshots WHERE keyspace_name = 'ks1' AND
true_size > 1080;
name | keyspace_name | table_name | created_at |
ephemeral | expires_at | size_on_disk | true_size
--+---++-+---+-+--+---
ks1 | ks1 | t1 | 2023-03-19 17:24:39.236000+ |
False | 2023-03-20 03:24:39.236000+ | 6186 | 1082
ks1 | ks1 | t2 | 2023-03-19 17:24:39.236000+ |
False | 2023-03-20 03:24:39.236000+ | 6186 | 1082
(2 rows)
{noformat}
Also, even though I suggested we use the {{id}} to identify a snapshot I
actually think we should use {{name}} instead since this is the term used to
describe snapshots on nodetool to avoid adding another term in addition to
{{tag}} and {{{}name{}}}:
{noformat}
$ nodetool snapshot
Requested creating snapshot(s) for [ks1] with snapshot name [ks1.t1] and
options {skipFlush=false}
$ nodetool listsnapshots
Snapshot Details:
Snapshot name Keyspace name Column family name True size Size on
disk Creation timeExpiration time
{noformat}
I made these changes on [this
commit|https://github.com/pauloricardomg/cassandra/commit/1654048f2ee2cf89d5362d6e6172acc0d4f90d46].
CI (queued):
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2359/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2359/pipeline]
> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
> class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>
> tag | keyspace_name | table_name | table_id | is_ephemeral | created_at |
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info |
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z |
> null |
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17702317#comment-17702317
]
Paulo Motta commented on CASSANDRA-18304:
-
Thanks for the review. Incorporated [~aleksey] {{WriteCallbackInfo}} cleanup
and moved shouldHint check to AbstractWriteResponseHandler#onFailure().
Also improved dtest a bit by removing 25s sleep for hint to be dispatched,
instead I check that {{StorageMetrics.totalHints.getCount()}} after write
timeout (15ms) to ensure hints are not submitted.
* [4.1 PR|https://github.com/apache/cassandra/pull/2196]
* [trunk PR|https://github.com/apache/cassandra/pull/2197]
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2357/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2357/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2358/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2358/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18304:
Status: Patch Available (was: Review In Progress)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697501#comment-17697501
]
Paulo Motta commented on CASSANDRA-18304:
-
Thanks! 4.1 build seems to be fine, trunk skipped some tests.. rebased and
resubmitted but still queued
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697176#comment-17697176
]
Paulo Motta edited comment on CASSANDRA-18304 at 3/7/23 3:22 PM:
-
Added dtest to reproduce issue.
Fix is to filter endpoints on with {{StorageProxy::shouldHint}} on
{{{}StorageProxy.submitHint{}}}, not sure if this has any unintended
consequences.
Can you take a look [~benedict] [~aleksey] ?
* [4.1 PR|https://github.com/apache/cassandra/pull/2196]
* [trunk PR|https://github.com/apache/cassandra/pull/2197]
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2327/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2327/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2333/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2333/pipeline]
was (Author: paulo):
Added dtest to reproduce issue.
Fix is to filter endpoints on with {{StorageProxy::shouldHint}} on
{{{}StorageProxy.submitHint{}}}, not sure if this has any unintended
consequences.
Can you take a look [~benedict] [~aleksey] ?
* [4.1 PR|https://github.com/apache/cassandra/pull/2196]
* [trunk PR|https://github.com/apache/cassandra/pull/2197]
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2327/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2327/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2328/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2328/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18304:
Test and Documentation Plan: changes
Status: Patch Available (was: Open)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697176#comment-17697176
]
Paulo Motta commented on CASSANDRA-18304:
-
Added dtest to reproduce issue.
Fix is to filter endpoints on with {{StorageProxy::shouldHint}} on
{{{}StorageProxy.submitHint{}}}, not sure if this has any unintended
consequences.
Can you take a look [~benedict] [~aleksey] ?
* [4.1 PR|https://github.com/apache/cassandra/pull/2196]
* [trunk PR|https://github.com/apache/cassandra/pull/2197]
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2327/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2327/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2328/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2328/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18304:
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Normal
Discovered By: Code Inspection
Fix Version/s: 4.1.1
Severity: Normal
Status: Open (was: Triage Needed)
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.1
>
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18304) hinted_handoff_enabled=false is not honored
Paulo Motta created CASSANDRA-18304:
---
Summary: hinted_handoff_enabled=false is not honored
Key: CASSANDRA-18304
URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
Project: Cassandra
Issue Type: Bug
Components: Consistency/Hints
Reporter: Paulo Motta
Assignee: Paulo Motta
I've had some dtests with disabled hints failing.
After investigation it seems that CASSANDRA-17164 moved hint submission on
timeout from
[RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
to
[AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
{{StorageProxy.shouldHint}} which ultimately checks if
{{{}hinted_handoff_enabled=true{}}}.
This could cause some tests which expect hints to be disabled to fail
intermittently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14796) Provide a tool which allows users to force manual compaction by ks.table and partition key
[
https://issues.apache.org/jira/browse/CASSANDRA-14796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14796:
Resolution: Duplicate
Status: Resolved (was: Open)
Closing as it seems to have been implemented by CASSANDRA-17537.
> Provide a tool which allows users to force manual compaction by ks.table and
> partition key
> --
>
> Key: CASSANDRA-14796
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14796
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Joey Lynch
>Priority: Low
>
> It's somewhat common to have a "hot partition" or otherwise "bad partition"
> that is causing neighbors to fail. In addition to CASSANDRA-12106, I think it
> would be really useful to have an optional partition key argument to
> {{nodetool compact}} (similar to {{getendpoints}}) which would determine
> which sstables a partition resides in (similar to {{getsstables}}) and then
> run manual compaction on just those sstables.
> I know at Netflix a common way that we "mitigate" these bad partitions is to
> delete them, but if the partition is really large it would be nice to be able
> to delete them _and_ then force compaction of sstables containing them.
> Obviously {{gc_grace}} get's in the way but it seems like a cheap/useful tool
> either way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18298) Remove WaitingOnFreeMemtableSpace metric
[ https://issues.apache.org/jira/browse/CASSANDRA-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-18298: Labels: lhf (was: ) > Remove WaitingOnFreeMemtableSpace metric > > > Key: CASSANDRA-18298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18298 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Paulo Motta >Priority: Normal > Labels: lhf > > It doesn't seem like this metric is [ever > updated|https://github.com/apache/cassandra/search?q=WaitingOnFreeMemtableSpace], > or ever was. > While we're at it we should remove any other unused metric. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18298) Remove WaitingOnFreeMemtableSpace metric
[ https://issues.apache.org/jira/browse/CASSANDRA-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-18298: Change Category: Code Clarity Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Remove WaitingOnFreeMemtableSpace metric > > > Key: CASSANDRA-18298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18298 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Paulo Motta >Priority: Normal > > It doesn't seem like this metric is [ever > updated|https://github.com/apache/cassandra/search?q=WaitingOnFreeMemtableSpace], > or ever was. > While we're at it we should remove any other unused metric. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18298) Remove WaitingOnFreeMemtableSpace metric
Paulo Motta created CASSANDRA-18298: --- Summary: Remove WaitingOnFreeMemtableSpace metric Key: CASSANDRA-18298 URL: https://issues.apache.org/jira/browse/CASSANDRA-18298 Project: Cassandra Issue Type: Task Components: Observability/Metrics Reporter: Paulo Motta It doesn't seem like this metric is [ever updated|https://github.com/apache/cassandra/search?q=WaitingOnFreeMemtableSpace], or ever was. While we're at it we should remove any other unused metric. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[
https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693679#comment-17693679
]
Paulo Motta commented on CASSANDRA-17561:
-
{quote}Why do we want to know what ranges that snapshot covers? What is the use
case?
{quote}
This would be additional metadata to enrich the snapshot manifest, just to
indicate that particular snapshot covers a subset of ranges (and not all ranges
as standard snapshots). While this could be useful if this functionality was
available to external users, I don't think this is a big deal for
internal/ephemeral snapshots since they're removed anyway after repair
completes.
{quote}btw isnt it true that as soon as there is some topology change and nodes
are not responsible for so and so ranges anymore, that information in snapshot
is pretty much useless, no?
{quote}
The metadata could be useful to easily identify that a snapshot is no longer
"valid" when a node's changes ranges. I think this would be a nice to have but
shouldn't block this ticket. Perhaps we can reconsider if we decide to expose
the "partial" snapshot functionality to external users.
> Diagnostic snapshot service should only snapshot mismatching ranges on
> preview repair mismatch
> --
>
> Key: CASSANDRA-17561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17561
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> We currently snapshot all sstables in a table when a preview repair mismatch
> occurs, we should only snapshot the sstables containing the mismatching ranges
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18271) Centralize all snapshot operations to SnapshotManager
[
https://issues.apache.org/jira/browse/CASSANDRA-18271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693677#comment-17693677
]
Paulo Motta commented on CASSANDRA-18271:
-
I was planning to do this on CASSANDRA-18111, but this work got a bit delayed.
If you're interested I can rebase my branch and post an initial patch for
review/discussion.
> Centralize all snapshot operations to SnapshotManager
> -
>
> Key: CASSANDRA-18271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18271
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, there is a lot of places where snapshotting logic is in place,
> scattered across the codebase. We should centralize snapshotting logic under
> SnapshotManager so every place in the code interacts only with that. This
> should remove whole class of possible synchronization problems. Merely
> looking into the code, all these methods are potentially unsafe.
> {code:java}
> public Map listSnapshots()
> protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
> Set snapshotDirs) {
> protected static SnapshotManifest maybeLoadManifest(String keyspace, String
> table, String tag, Set snapshotDirs)
> public List listEphemeralSnapshots()
> private List listAllSnapshots()
> protected Map> listSnapshotDirsByTag()
> public boolean snapshotExists(String snapshotName)
> public static void clearSnapshot(String snapshotName, List
> tableDirectories, RateLimiter snapshotRateLimiter)
> public static void removeSnapshotDirectory(RateLimiter snapshotRateLimiter,
> File snapshotDir)
> public long trueSnapshotsSize()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690467#comment-17690467 ] Paulo Motta commented on CASSANDRA-17561: - Currently the snapshots semantics is that it will snapshot all ranges for a node. If we're snapshotting a subset of ranges, should we include the ranges snapshotted in the snapshot manifest json? > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18208) Use default JVM thread stack size in config files
[ https://issues.apache.org/jira/browse/CASSANDRA-18208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682276#comment-17682276 ] Paulo Motta edited comment on CASSANDRA-18208 at 1/30/23 9:02 PM: -- seems to be related to CASSANDRA-15446. -Agree we should just use defaults when possible, but we should probably confirm why this parameter was added in the first place to see if removing it won't cause any issues.- (seems like we use this because the JVM default is too low in some architectures) was (Author: paulo): seems to be related to CASSANDRA-15446. Agree we should just use defaults, but we should probably confirm why this parameter was added in the first place to see if removing it won't cause any issues. > Use default JVM thread stack size in config files > - > > Key: CASSANDRA-18208 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18208 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Rishi Misra >Priority: Normal > Fix For: 4.x > > Attachments: jvmstack.patch > > > JVM per-thread stack sized defined > [here|https://github.com/apache/cassandra/blob/15d47f8e3f8b17e26ffe54cdb16b8a1d3435ebfa/conf/jvm-server.options#L103] > and > [here|https://github.com/apache/cassandra/blob/15d47f8e3f8b17e26ffe54cdb16b8a1d3435ebfa/build.xml#L170] > is too small for certain JVMs resulting in java.lang.StackOverflowError when > starting the server (see attached stack trace). Should Cassandra allow JVMs > to pick up their default stack size? I know it is possible to change the > values in the config files but I think it will be useful for the defaults to > be used. A simple patch might be: > // > diff --git a/build.xml b/build.xml > index 3c29f8c365..fcf63e16aa 100644 > --- a/build.xml > +++ b/build.xml > @@ -165,9 +165,7 @@ > > > > - > - > > > diff --git a/conf/jvm-server.options b/conf/jvm-server.options > index 46967f4ad7..5c84fae2fd 100644 > --- a/conf/jvm-server.options > +++ b/conf/jvm-server.options > @@ -101,7 +101,6 @@ > -XX:+HeapDumpOnOutOfMemoryError > # Per-thread stack size. > --Xss256k > # Make sure all memory is faulted and zeroed on startup. > # This helps prevent soft faults in containers and makes > // > > Startup failure: > /=/ > $ ./bin/cassandra -f > > Exception (java.lang.StackOverflowError) encountered during startup: null > java.lang.StackOverflowError > at sun.misc.URLClassPath.getLoader(URLClassPath.java:556) > at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:494) > at sun.misc.URLClassPath.getResource(URLClassPath.java:248) > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at java.lang.ClassLoader.loadClass(ClassLoader.java:405) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:756) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) > at java.net.URLClassLoader.access$100(URLClassLoader.java:74) > at java.net.URLClassLoader$1.run(URLClassLoader.java:369) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:756) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) > at java.net.URLClassLoader.access$100(URLClassLoader.java:74) > at java.net.URLClassLoader$1.run(URLClassLoader.java:369) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at
[jira] [Commented] (CASSANDRA-18208) Use default JVM thread stack size in config files
[ https://issues.apache.org/jira/browse/CASSANDRA-18208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17682276#comment-17682276 ] Paulo Motta commented on CASSANDRA-18208: - seems to be related to CASSANDRA-15446. Agree we should just use defaults, but we should probably confirm why this parameter was added in the first place to see if removing it won't cause any issues. > Use default JVM thread stack size in config files > - > > Key: CASSANDRA-18208 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18208 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Rishi Misra >Priority: Normal > Fix For: 4.x > > Attachments: jvmstack.patch > > > JVM per-thread stack sized defined > [here|https://github.com/apache/cassandra/blob/15d47f8e3f8b17e26ffe54cdb16b8a1d3435ebfa/conf/jvm-server.options#L103] > and > [here|https://github.com/apache/cassandra/blob/15d47f8e3f8b17e26ffe54cdb16b8a1d3435ebfa/build.xml#L170] > is too small for certain JVMs resulting in java.lang.StackOverflowError when > starting the server (see attached stack trace). Should Cassandra allow JVMs > to pick up their default stack size? I know it is possible to change the > values in the config files but I think it will be useful for the defaults to > be used. A simple patch might be: > // > diff --git a/build.xml b/build.xml > index 3c29f8c365..fcf63e16aa 100644 > --- a/build.xml > +++ b/build.xml > @@ -165,9 +165,7 @@ > > > > - > - > > > diff --git a/conf/jvm-server.options b/conf/jvm-server.options > index 46967f4ad7..5c84fae2fd 100644 > --- a/conf/jvm-server.options > +++ b/conf/jvm-server.options > @@ -101,7 +101,6 @@ > -XX:+HeapDumpOnOutOfMemoryError > # Per-thread stack size. > --Xss256k > # Make sure all memory is faulted and zeroed on startup. > # This helps prevent soft faults in containers and makes > // > > Startup failure: > /=/ > $ ./bin/cassandra -f > > Exception (java.lang.StackOverflowError) encountered during startup: null > java.lang.StackOverflowError > at sun.misc.URLClassPath.getLoader(URLClassPath.java:556) > at sun.misc.URLClassPath.getNextLoader(URLClassPath.java:494) > at sun.misc.URLClassPath.getResource(URLClassPath.java:248) > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at java.lang.ClassLoader.loadClass(ClassLoader.java:405) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:756) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) > at java.net.URLClassLoader.access$100(URLClassLoader.java:74) > at java.net.URLClassLoader$1.run(URLClassLoader.java:369) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:756) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) > at java.net.URLClassLoader.access$100(URLClassLoader.java:74) > at java.net.URLClassLoader$1.run(URLClassLoader.java:369) > at java.net.URLClassLoader$1.run(URLClassLoader.java:363) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:362) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:756) > at >
[jira] [Comment Edited] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681030#comment-17681030 ] Paulo Motta edited comment on CASSANDRA-16325 at 1/26/23 7:12 PM: -- build failed due to CASSANDRA-18197 Resubmitted CI: [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2234/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2234/pipeline] was (Author: paulo): build failed due to CASSANDRA-18197 Resubmitted CI: !https://ci-cassandra.apache.org/job/Cassandra-devbranch/2234/badge/icon! > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17681030#comment-17681030 ] Paulo Motta commented on CASSANDRA-16325: - build failed due to CASSANDRA-18197 Resubmitted CI: !https://ci-cassandra.apache.org/job/Cassandra-devbranch/2234/badge/icon! > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680808#comment-17680808 ] Paulo Motta commented on CASSANDRA-16325: - LGTM, nice work Isaac! Prepared patch for commit [here|https://github.com/pauloricardomg/cassandra/commit/49946329d05b736943678345c2e110ce315940bc] and submitted a final round of CI: * [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2228/] (queued) ok to merge if CI looks good [~smiklosovic]? > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680808#comment-17680808 ] Paulo Motta edited comment on CASSANDRA-16325 at 1/25/23 9:15 PM: -- LGTM, nice work Isaac! Prepared patch for commit [here|https://github.com/pauloricardomg/cassandra/commit/49946329d05b736943678345c2e110ce315940bc] and submitted a final round of CI: * [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2229/] (queued) ok to merge if CI looks good [~smiklosovic]? was (Author: paulo): LGTM, nice work Isaac! Prepared patch for commit [here|https://github.com/pauloricardomg/cassandra/commit/49946329d05b736943678345c2e110ce315940bc] and submitted a final round of CI: * [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2228/] (queued) ok to merge if CI looks good [~smiklosovic]? > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16325: Status: Review In Progress (was: Changes Suggested) > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 50m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16290) Consistency can be violated when bootstrap or decommission is resumed after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680790#comment-17680790
]
Paulo Motta commented on CASSANDRA-16290:
-
unassigning since I don't think this is being actively worked on
> Consistency can be violated when bootstrap or decommission is resumed after
> node restart
>
>
> Key: CASSANDRA-16290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16290
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Since CASSANDRA-12008, successfully transferred ranges during decommission
> are saved on the {{system.transferred_ranges}} table. This allow skipping
> ranges already transferred when a failed decommission is retried with
> {{nodetool decommission}}.
> If instead of resuming the decommission, an operator restarts the node, waits
> N minutes and then performs a new decommission, the previously transferred
> ranges will be skipped during streaming, and any writes received by the
> decommissioned node during these N minutes will not be replicated to the new
> range owner, what violates consistency.
> This issue is analogous to the issue mentioned [on this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234]
> for resumable bootstrap (CASSANDRA-8838).
> In order to prevent consistency violations we should clear the
> {{system.transferred_ranges}} state during node restart, and maybe a system
> property to disable it. While we're at this, we should change the default of
> {{-Dcassandra.reset_bootstrap_progress}} to {{true}} to clear the
> {{system.available_ranges}} state by default when a bootstrapping node is
> restarted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16290) Consistency can be violated when bootstrap or decommission is resumed after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta reassigned CASSANDRA-16290:
---
Assignee: (was: David Paulk)
> Consistency can be violated when bootstrap or decommission is resumed after
> node restart
>
>
> Key: CASSANDRA-16290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16290
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Since CASSANDRA-12008, successfully transferred ranges during decommission
> are saved on the {{system.transferred_ranges}} table. This allow skipping
> ranges already transferred when a failed decommission is retried with
> {{nodetool decommission}}.
> If instead of resuming the decommission, an operator restarts the node, waits
> N minutes and then performs a new decommission, the previously transferred
> ranges will be skipped during streaming, and any writes received by the
> decommissioned node during these N minutes will not be replicated to the new
> range owner, what violates consistency.
> This issue is analogous to the issue mentioned [on this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234]
> for resumable bootstrap (CASSANDRA-8838).
> In order to prevent consistency violations we should clear the
> {{system.transferred_ranges}} state during node restart, and maybe a system
> property to disable it. While we're at this, we should change the default of
> {{-Dcassandra.reset_bootstrap_progress}} to {{true}} to clear the
> {{system.available_ranges}} state by default when a bootstrapping node is
> restarted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Fix Version/s: 4.0.8 4.1.1 4.2 (was: 4.0.x) Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/8bb9c72f582de6bcc39522ba9ade91fd5bc22f67 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.8, 4.1.1, 4.2 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Ready to Commit (was: Changes Suggested) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 3h 10m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-11537:
Fix Version/s: 4.2
Source Control Link:
https://github.com/apache/cassandra/commit/035705f49464a4854482e1f1280a7af45f7f0203
(was: https://github.com/apache/cassandra/pull/2060)
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
committed as
[035705f49464a4854482e1f1280a7af45f7f0203|https://github.com/apache/cassandra/commit/035705f49464a4854482e1f1280a7af45f7f0203]
to trunk. Thanks!
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Fix For: 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-11537:
Status: Ready to Commit (was: Review In Progress)
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready
[
https://issues.apache.org/jira/browse/CASSANDRA-11537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-11537:
Status: Review In Progress (was: Patch Available)
> Give clear error when certain nodetool commands are issued before server is
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability, Local/Startup and Shutdown
>Reporter: Edward Capriolo
>Assignee: William Nguyen
>Priority: Low
> Labels: lhf
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As an ops person upgrading and servicing Cassandra servers, I require a more
> clear message when I issue a nodetool command that the server is not ready
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool
> scrub/compact/updatess etc you get unfriendly assertion. An exception would
> be easier to understand. Also if a user has turned assertions off it is
> unclear what might happen.
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process.
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1:
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678437#comment-17678437 ] Paulo Motta edited comment on CASSANDRA-16418 at 1/20/23 6:45 PM: -- Resubmitted CI after [test fix|https://github.com/linzuro/cassandra/commit/8de9c73d28291d2df67727ffcb7292f8c21b3442]: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2205|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/] (finished)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2206|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2206/] (finished)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2207|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/] (finished)| was (Author: paulo): Resubmitted CI after [test fix|https://github.com/linzuro/cassandra/commit/8de9c73d28291d2df67727ffcb7292f8c21b3442]: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2205|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/] (running)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2206|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2206/] (running)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2207|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/] (queued)| > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 3h > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679268#comment-17679268 ] Paulo Motta commented on CASSANDRA-16418: - Test failures look unrelated - for instance [test_decommissioned_node_cant_rejoin|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/testReport/junit/dtest.topology_test/TestTopology/test_decommissioned_node_cant_rejoin/] failed on 4.0 and [test_simultaneous_bootstrap|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/testReport/junit/dtest-novnode.bootstrap_test/TestBootstrap/test_simultaneous_bootstrap/] on trunk, but they don't seem to be at all related to this ticket. I ran these tests locally on the respective branches and they're passing. ok to merge [~smiklosovic]? > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 3h > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678437#comment-17678437 ] Paulo Motta commented on CASSANDRA-16418: - Resubmitted CI after [test fix|https://github.com/linzuro/cassandra/commit/8de9c73d28291d2df67727ffcb7292f8c21b3442]: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2205|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2205/] (running)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2206|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2206/] (running)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2207|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2207/] (queued)| > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 3h > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677987#comment-17677987 ] Paulo Motta edited comment on CASSANDRA-16418 at 1/18/23 7:04 PM: -- Prepared [~linzuro]'s patch for commit on 4.0/4.1/trunk and submitted CI: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2202|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2202/] (finished)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2203|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2203/] (finished)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2204|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2204/] (finished)| was (Author: paulo): Prepared [~linzuro]'s patch for commit on 4.0/4.1/trunk and submitted CI: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2202|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2202/] (running)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2203|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2202/] (running)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2204|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2204/] (queued)| > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Changes Suggested (was: Review In Progress) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678335#comment-17678335 ] Paulo Motta commented on CASSANDRA-16418: - There seems to be a legit failure on [CleanupTest|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2202/testReport/org.apache.cassandra.db/CleanupTest/testCleanup/] > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Review In Progress (was: Needs Committer) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[
https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678015#comment-17678015
]
Paulo Motta commented on CASSANDRA-16325:
-
The new approach looks good to me. Right now,
{{testMetricsUpdateIncrementallyWithRepairAndStreamingBetweenNodes}} and
{{testMetricsUpdateIncrementallyWithRebuildAndStreamingBetweenNodes}} are only
testing the uncompressed/partial stream path. I think we should extend these
tests to also test the metrics are working correctly for compressed and
{{stream_entire_sstables=true}}
I don't expect these more frequent streamed bytes counter updates to have any
noticeable impact on streaming performance, but if processing of downstream
streaming listeners turn out to be a bottleneck I think we should send the
notifications on a separate thread versus adding special logic to batch metric
updates to not make this overly complex.
> Update streaming metrics incrementally
> --
>
> Key: CASSANDRA-16325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16325
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.2
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> Currently the inbound and outbound streamed bytes metrics are incremented
> after each file is streamed, what doesn't represent the current number of
> bytes streamed since it can take a long time for a large file to be streamed.
> We should update the metric incrementally as data is streamed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677987#comment-17677987 ] Paulo Motta commented on CASSANDRA-16418: - Prepared [~linzuro]'s patch for commit on 4.0/4.1/trunk and submitted CI: |branch||CI|| |[CASSANDRA-16418-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.0]|[#2202|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2202/] (running)| |[CASSANDRA-16418-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-4.1]|[#2203|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2202/] (running)| |[CASSANDRA-16418-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418-trunk]|[#2204|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2204/] (queued)| > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Status: Patch Available (was: Review In Progress)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Resolution: Not A Problem
Status: Resolved (was: Open)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Status: Open (was: Patch Available)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677971#comment-17677971
]
Paulo Motta commented on CASSANDRA-15458:
-
Thanks Brandon
Tests committed to trunk as
[1528798a5bb36187cf2b952b5b5a8b0982d262fb|https://github.com/apache/cassandra/commit/1528798a5bb36187cf2b952b5b5a8b0982d262fb],
will close as Not a Problem.
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Status: Review In Progress (was: Needs Committer)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677958#comment-17677958
]
Paulo Motta commented on CASSANDRA-15458:
-
I noticed this issue is a duplicate of CASSANDRA-10263 which was closed as not
a problem. Since this seems to be a recurrent confusion I created
CASSANDRA-18170 to document this behavior.
I squashed [~yziadeh]'s tests validating the quoting behavior into this commit:
[https://github.com/pauloricardomg/cassandra/commit/437acae1e80f12e02e317168402874c64c606188]
CI apparently looks good:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2201/]:
*
[SelectTest|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2201/testReport/org.apache.cassandra.cql3.validation.operations/SelectTest/]
*
[test_cqlsh_completion|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2201/testReport/cqlshlib.python3.jdk8.cython.test.test_cqlsh_completion/]
*
[test_cqlsh_output|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2201/testReport/cqlshlib.python3.jdk8.cython.test.test_cqlsh_output/]
[~brandon.williams] ok to commit the tests and close this as not a problem?
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Status: Needs Committer (was: Patch Available)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18170) Document cqlsh single quote escaping behavior on complex vs simple types
Paulo Motta created CASSANDRA-18170:
---
Summary: Document cqlsh single quote escaping behavior on complex
vs simple types
Key: CASSANDRA-18170
URL: https://issues.apache.org/jira/browse/CASSANDRA-18170
Project: Cassandra
Issue Type: Task
Components: Documentation, Documentation/Website, Tool/cqlsh
Reporter: Paulo Motta
cqlsh escapes single quotes on complex types but not on text types:
Table: {{CREATE TABLE test (name text, foo map, PRIMARY KEY(name));}}
Insert: {code}INSERT INTO test (name, foo) VALUES (
'jos''emy',{'foo':'josemy''s houñse'});{code}
Query: {{SELECT * FROM test;}}
{code}
name| foo
---+-
jos'emy | {'foo': 'josemy''s houñse'}
{code}
This behavior is confusing because simple text fields containing single quotes
are not escaped on cqlsh, while complex types (such as collections or UDTs) are
escaped. A couple of tickets were created to clarify this behavior:
CASSANDRA-10263 and CASSANDRA-15458.
We should probably document this behavior on cqlsh documentation to avoid
confusion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Keyspace named "snapshots" is empty after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14013:
Fix Version/s: 4.0.8
4.1.1
4.2
(was: 4.x)
(was: 4.0.x)
(was: 4.1.x)
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/6e6846892a5d7ec2feaf2c35d380ed5975d09517
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[6e6846892a5d7ec2feaf2c35d380ed5975d09517|https://github.com/apache/cassandra/commit/6e6846892a5d7ec2feaf2c35d380ed5975d09517]
to {{cassandra-4.0}} and merged to
[cassandra-4.1|https://github.com/apache/cassandra/commit/c9968a8e95253a23846be1b5f502773a1eeea48d]
and
[trunk|https://github.com/apache/cassandra/commit/6501f576e7c663d285a4db207e6b3dc7f887e8f4]
(regex-based version).
Created CASSANDRA-18168 to serialize keyspace/table metadata on
{{StatsMetadata}} component.
> Keyspace named "snapshots" is empty after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18168) Serialize sstable keyspace and table metadata on StatsMetadata component
Paulo Motta created CASSANDRA-18168:
---
Summary: Serialize sstable keyspace and table metadata on
StatsMetadata component
Key: CASSANDRA-18168
URL: https://issues.apache.org/jira/browse/CASSANDRA-18168
Project: Cassandra
Issue Type: Improvement
Components: Local/SSTable
Reporter: Paulo Motta
Currently Cassandra relies on the parent directory structure to figure out the
keyspace/table of a given sstable:
{{$data_dir/$keyspace/$tablename-$tableId/$sstable}}.
Offline tools require sstables to be placed in the well-defined directory
structure above to correctly parse keyspace/table information.
We can improve this by serializing keyspace/table metadata (such as
keyspace/table names and table id) into the {{StatsMetadata}} component, so
offline tools can read sstables from any parent directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18168) Serialize sstable keyspace and table metadata on StatsMetadata component
[
https://issues.apache.org/jira/browse/CASSANDRA-18168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-18168:
Labels: lhf (was: )
> Serialize sstable keyspace and table metadata on StatsMetadata component
>
>
> Key: CASSANDRA-18168
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18168
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> Currently Cassandra relies on the parent directory structure to figure out
> the keyspace/table of a given sstable:
> {{$data_dir/$keyspace/$tablename-$tableId/$sstable}}.
> Offline tools require sstables to be placed in the well-defined directory
> structure above to correctly parse keyspace/table information.
> We can improve this by serializing keyspace/table metadata (such as
> keyspace/table names and table id) into the {{StatsMetadata}} component, so
> offline tools can read sstables from any parent directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14291) Nodetool command to recreate SSTable components
[
https://issues.apache.org/jira/browse/CASSANDRA-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14291:
Labels: lhf (was: 4.0-feature-freeze-review-requested)
> Nodetool command to recreate SSTable components
> ---
>
> Key: CASSANDRA-14291
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14291
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: lhf
>
> Need a JMX/Nodetool command to recreate components for SSTables without
> re-writing the data files.
> Possible implementation idea:
> Create a {{nodetool (recreate|regen)component}} command that would enable you
> to recreate specific components of an SSTable, and also allow specifying
> SSTables or columnfamilies.
> I'd say a flag for a list of components and a flag for SSTables with
> keyspace.columnfamilies as positional arguments would work
> Alternatively this could become part of upgradesstables, but would likely
> make that command a bit bloated.
> Background:
> In CASSANDRA-11163 we changed it so summaries and bloomfilters were not
> regenerated or persisted on startup. This means we would rely on
> compactions/upgrades to regenerate the bloomfilter (or other components)
> after a configuration change. While this works, it's pretty inefficient on
> large tables just because you changed the bloomfilter size or summary chunk
> sizes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Keyspace named "snapshots" is empty after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14013:
Status: Ready to Commit (was: Review In Progress)
> Keyspace named "snapshots" is empty after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Keyspace named "snapshots" is empty after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14013:
Reviewers: Paulo Motta, Paulo Motta (was: Benjamin Lerer, Michael Semb
Wever, Paulo Motta)
Paulo Motta, Paulo Motta (was: Paulo Motta)
Status: Review In Progress (was: Patch Available)
> Keyspace named "snapshots" is empty after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Keyspace named "snapshots" is empty after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14013:
Summary: Keyspace named "snapshots" is empty after service restart (was:
Data loss in snapshots keyspace after service restart)
> Keyspace named "snapshots" is empty after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676406#comment-17676406
]
Paulo Motta commented on CASSANDRA-14013:
-
Resubmitted 4.1 CI on
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2187/
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-14013:
Reviewers: Benjamin Lerer, Michael Semb Wever, Paulo Motta (was: Benjamin
Lerer, Michael Semb Wever)
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Mentor: Paulo Motta (was: Benjamin Lerer)
Status: Changes Suggested (was: Review In Progress)
cancelling patch as there seems to some failures on
[TestCqlshCompletion|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2159/]
due to creation of new table
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15458) CQL: Unable to escape single quote in a map attribute
[
https://issues.apache.org/jira/browse/CASSANDRA-15458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-15458:
Status: Review In Progress (was: Needs Committer)
> CQL: Unable to escape single quote in a map attribute
> ---
>
> Key: CASSANDRA-15458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15458
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter, CQL/Semantics
>Reporter: Abhijeet Singh
>Assignee: Yaman Ziadeh
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Attachments: cass-screen.png
>
>
> h3. Overview
> For {{text}} attributes, CQL allows escaping single quote [using additional
> single
> quote|http://mail-archives.apache.org/mod_mbox/cassandra-user/201108.mbox/%3c20110803152250.294...@gmx.net%3E].
> But applying the same syntax for a {{map}} attribute does not
> work. Inconsistent behavior was observed between {{text}} datatype and
> {{map}} datatype.
> h3. CQL semantic proposal
> Cassandra (CQL) should apply same escaping semantics on {{text}} and
> text-within-map {{map}} datatypes.
> h3. Reproducing the bug:
> CREATE query:
> {code:java}
> CREATE TABLE university.test (id int, data map, PRIMARY KEY
> (id));{code}
> INSERT query:
> {code:java}
> insert into university.test (id, data) values(1, {1:'I''m newb'});{code}
> On running the aforementioned INSERT query, Cassandra inserts and returns
> {{\{1: 'I''m newb'}}} while the expected result is {{\{1: 'I'm newb'}}}
> h3. Technical details
> OS: CentOS 7
> Kernel: Linux 3.10.0-1062.9.1.el7.x86_64
> Cassandra version: 3.11.5
> Screenshot: [Output after SELECT query|https://i.stack.imgur.com/PLAan.png]
>
> +Additional information for newcomers:+
> The issue seems to come from the ANTLR Lexer logic for {{STRING_LITERAL}}. A
> unit test should also be added in {{SelectTest}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Patch Available (was: Ready to Commit) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Needs Committer (was: Patch Available) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675740#comment-17675740 ] Paulo Motta commented on CASSANDRA-16418: - I rebased and squashed Lindsey's commit [on this branch|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418] + updated tests [from this commit|https://github.com/pauloricardomg/cassandra/commit/702f77d247893a51461823268ad6a20cd6c1a021] and submitted CI on https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-16418 (still queued). I think this is ready for a second round of review. [~JoshuaMcKenzie] [~stefan.miklosovic] would you have cycles to take a look? > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Status: Ready to Commit (was: Changes Suggested) > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[
https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17675737#comment-17675737
]
Paulo Motta commented on CASSANDRA-16418:
-
In order to check the tests were reliably reproducing the issue on Lindsey's
[branch|https://github.com/apache/cassandra/pull/2061] I commented out the
following excerpt:
{noformat}
InetAddressAndPort localAddress =
FBUtilities.getBroadcastAddressAndPort();
Integer pendingRangesCount =
tokenMetadata.getPendingRanges(keyspaceName, localAddress).size();
if (pendingRangesCount > 0)
{
throw new RuntimeException("Node is involved in cluster membership
changes. Not safe to run cleanup.");
}
{noformat}
And expected both
[testCleanupFailsDuringOngoingDecommission|https://github.com/apache/cassandra/pull/2061/files#diff-68d2cd75caa0e4091c7206717116594bdcb0aab38f72f6d6afa44eac60466e13R41]
and
[testCleanupFailsDuringOngoingBootstrap|https://github.com/apache/cassandra/pull/2061/files#diff-68d2cd75caa0e4091c7206717116594bdcb0aab38f72f6d6afa44eac60466e13R85]
to fail.
Even though the tests failed most of the time, sometimes the tests passed so
data was not being wrongly cleaned up as expected.
The reason for this is that these tests require that the cleanup is executed
between the sstables are transferred by streaming and the ring membership
operation is finished. There is a small chance cleanup is not executed within
this window so the issue will not reproduce, especially if we run this test on
faster hardware.
I took a slightly different testing approach on [this
commit|https://github.com/pauloricardomg/cassandra/blob/702f77d247893a51461823268ad6a20cd6c1a021/test/distributed/org/apache/cassandra/distributed/test/ring/CleanupFailureTest.java#L40]
that inserts data while a node is bootstrapping or decommissioning and checks
the data is present after a cleanup is run. This was able to reliably reproduce
the issue when the excerpt above is commented out.
The updated test is more deterministic because we don't depend on streaming nor
timing. Furthermore this makes the test faster since we don't need so many rows
to reproduce the issue, which is needed with the streaming approach.
A nice benefit of this approach is that since we only run cleanup a single time
while the node is bootstrapping/decommissioning, we're able to [verify that the
cleanup fails with the expected error
message|https://github.com/pauloricardomg/cassandra/blob/702f77d247893a51461823268ad6a20cd6c1a021/test/distributed/org/apache/cassandra/distributed/test/ring/CleanupFailureTest.java#L105].
> Unsafe to run nodetool cleanup during bootstrap or decommission
> ---
>
> Key: CASSANDRA-16418
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16418
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: James Baker
>Assignee: Lindsey Zurovchak
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> What we expected: Running a cleanup is a safe operation; the result of
> running a query after a cleanup should be the same as the result of running a
> query before a cleanup.
> What actually happened: We ran a cleanup during a decommission. All the
> streamed data was silently deleted, the bootstrap did not fail, the cluster's
> data after the decommission was very different to the state before.
> Why: Cleanups do not take into account pending ranges and so the cleanup
> thought that all the data that had just been streamed was redundant and so
> deleted it. We think that this is symmetric with bootstraps, though have not
> verified.
> Not sure if this is technically a bug but it was very surprising (and
> seemingly undocumented) behaviour.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16325) Update streaming metrics incrementally
[
https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656757#comment-17656757
]
Paulo Motta commented on CASSANDRA-16325:
-
bq. ISTM we might benefit from a simple threshold counter inside
CassandraStreamWriter where it'll update the metrics every N multiples of
CassandraStreamWriter.DEFAULT_CHUNK_SIZE so we don't spam the metrics updates.
Makes sense, but I think we should keep this metric buffering logic inside
{{FileStreamMetricsListener}} so it's transparent to different readers/writers.
We should also probably make the threshold configurable via a system property.
> Update streaming metrics incrementally
> --
>
> Key: CASSANDRA-16325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16325
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Paulo Motta
>Assignee: Isaac Reath
>Priority: Normal
> Labels: lhf
> Fix For: 4.2
>
> Time Spent: 10h 10m
> Remaining Estimate: 0h
>
> Currently the inbound and outbound streamed bytes metrics are incremented
> after each file is streamed, what doesn't represent the current number of
> bytes streamed since it can take a long time for a large file to be streamed.
> We should update the metric incrementally as data is streamed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16325: Fix Version/s: 4.2 (was: 5.x) > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 4.2 > > Time Spent: 10h 10m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16418) Unsafe to run nodetool cleanup during bootstrap or decommission
[ https://issues.apache.org/jira/browse/CASSANDRA-16418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16418: Fix Version/s: 4.0.x > Unsafe to run nodetool cleanup during bootstrap or decommission > --- > > Key: CASSANDRA-16418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16418 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Bootstrap and Decommission >Reporter: James Baker >Assignee: Lindsey Zurovchak >Priority: Normal > Fix For: 4.0.x > > Time Spent: 50m > Remaining Estimate: 0h > > What we expected: Running a cleanup is a safe operation; the result of > running a query after a cleanup should be the same as the result of running a > query before a cleanup. > What actually happened: We ran a cleanup during a decommission. All the > streamed data was silently deleted, the bootstrap did not fail, the cluster's > data after the decommission was very different to the state before. > Why: Cleanups do not take into account pending ranges and so the cleanup > thought that all the data that had just been streamed was redundant and so > deleted it. We think that this is symmetric with bootstraps, though have not > verified. > Not sure if this is technically a bug but it was very surprising (and > seemingly undocumented) behaviour. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16325) Update streaming metrics incrementally
[ https://issues.apache.org/jira/browse/CASSANDRA-16325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-16325: Fix Version/s: 5.x > Update streaming metrics incrementally > -- > > Key: CASSANDRA-16325 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16325 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Paulo Motta >Assignee: Isaac Reath >Priority: Normal > Labels: lhf > Fix For: 5.x > > Time Spent: 10h 10m > Remaining Estimate: 0h > > Currently the inbound and outbound streamed bytes metrics are incremented > after each file is streamed, what doesn't represent the current number of > bytes streamed since it can take a long time for a large file to be streamed. > We should update the metric incrementally as data is streamed. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656359#comment-17656359
]
Paulo Motta commented on CASSANDRA-14013:
-
Good catch! I've added two test cases on {{DescriptorTest}} for non .db files
[on this
commit|https://github.com/pauloricardomg/cassandra/commit/d5232cbc225b7d7d7b1adf67bd819dfea0d00b79].
I've incorporated [your
commit|https://github.com/pauloricardomg/cassandra/pull/2/commits/d5eb3b69bb4d7262fd19368082dbd466b77e7b90]
+ the test change
[above|https://github.com/pauloricardomg/cassandra/commit/d5232cbc225b7d7d7b1adf67bd819dfea0d00b79]
into the trunk branch, rebased and resubmitted CI for all branches:
|branch||CI||
|[CASSANDRA-14013-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-4.0]|[#2171|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2171/]
(running)|
|[CASSANDRA-14013-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-4.1]|[#2170|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2170/]
(running)|
|[CASSANDRA-14013-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-trunk]|[#2169|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2169/]
(running)|
After CI looks good for all branches this should be good to go from my side.
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
