[jira] [Commented] (CASSANDRA-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676806#comment-17676806 ] Stefan Miklosovic commented on CASSANDRA-18152: --- [~adelapena] thanks for the review, I have reworked it so we do not need to have system property. > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-17427) Improve unit tests performance
[ https://issues.apache.org/jira/browse/CASSANDRA-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676790#comment-17676790 ] Michael Semb Wever commented on CASSANDRA-17427: https://ci-cassandra.apache.org/job/Cassandra-devbranch/2195/ > Improve unit tests performance > -- > > Key: CASSANDRA-17427 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17427 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > There a couple of small improvements to run unit tests a bit faster -- 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-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676789#comment-17676789 ] Michael Semb Wever commented on CASSANDRA-18027: Based on folk's objections not to change the GC default in 4.1.x, here's the appropriate patch on the cassandra-4.1 https://github.com/apache/cassandra/compare/cassandra-4.1...thelastpickle:cassandra:mck/18027/4.1 (patch for trunk is in ticket description) > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- 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-17427) Improve unit tests performance
[ https://issues.apache.org/jira/browse/CASSANDRA-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676784#comment-17676784 ] Michael Semb Wever commented on CASSANDRA-17427: there's been some additions to the PR yes. and let me run ci-cassandra again, there's been a few network timeouts and full disks there… > Improve unit tests performance > -- > > Key: CASSANDRA-17427 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17427 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > There a couple of small improvements to run unit tests a bit faster -- 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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676783#comment-17676783
]
Brandon Williams commented on CASSANDRA-18141:
--
We aren't changing python2, only python3's display.
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676780#comment-17676780
]
Ekaterina Dimitrova edited comment on CASSANDRA-18141 at 1/13/23 10:27 PM:
---
Actually looking here, I think I am wrong and it could be ok:
[https://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#python-2-1]
Please check the recommendations. Actually this is not from the official docs,
probably good to double check there. Also, I am wondering whether we want some
Python 2 test. This goes to patch release so I want to be extra careful
was (Author: e.dimitrova):
Actually looking here, I think I am wrong and it could be ok:
[https://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#python-2-1]
Please check the recommendations. Actually this is not from the official docs,
probably good to double check there. Also, I am wondering whether we want some
Python 2 test. This goes to patch release
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676780#comment-17676780
]
Ekaterina Dimitrova edited comment on CASSANDRA-18141 at 1/13/23 10:26 PM:
---
Actually looking here, I think I am wrong and it could be ok:
[https://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#python-2-1]
Please check the recommendations. Actually this is not from the official docs,
probably good to double check there. Also, I am wondering whether we want some
Python 2 test. This goes to patch release
was (Author: e.dimitrova):
Actually looking here, I think I am wrong and it could be ok:
[https://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#python-2-1]
Please check the recommendations
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676780#comment-17676780
]
Ekaterina Dimitrova commented on CASSANDRA-18141:
-
Actually looking here, I think I am wrong and it could be ok:
[https://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#python-2-1]
Please check the recommendations
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676779#comment-17676779
]
Ekaterina Dimitrova commented on CASSANDRA-18141:
-
Thanks [~brandon.williams]
Question: We test this with Python 3 as far as I can see but isn't Python 2
only deprecated in 4.0, so is this going to break there?
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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-18141) Cqlsh incorrectly formats duration
[
https://issues.apache.org/jira/browse/CASSANDRA-18141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18141:
Status: Review In Progress (was: Needs Committer)
> Cqlsh incorrectly formats duration
> --
>
> Key: CASSANDRA-18141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18141
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Maciej Sokol
>Assignee: Maciej Sokol
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like something broke between C* 3.11 and C* 4.X when it comes to
> duration types.
> Example:
> CREATE KEYSPACE users WITH replication = \{'class':
> 'NetworkTopologyStrategy', 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (email text,la_duration
> duration,PRIMARY KEY(email));
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', 12h30m30s250ms);
> INSERT INTO users.user_credentials_by_email (email, la_duration ) VALUES (
> 'te...@test.com', PT12H30M);
> 3.11:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 5.0.1 | Cassandra 3.11.15-SNAPSHOT | CQL spec 3.4.4 | Native protocol
> v4]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +
> te...@test.com | 12h
> te...@test.com | 12h30m30s250ms
> te...@test.com | 12h30m
> te...@test.com | 12h30m
> te...@test.com | 12h30m30s
> (5 rows)
> 4.X:
> cassandra@cqlsh> SHOW VERSION ;
> [cqlsh 6.0.0 | Cassandra 4.0.8-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
> cassandra@cqlsh> SELECT * FROM users.user_credentials_by_email ;
> email | la_duration
> +-
> te...@test.com | 12.0h
> te...@test.com | 12.5084028h30.5041666m30.25s250.0ms
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.5h30.0m
> te...@test.com | 12.508h30.5m30.0s
> (5 rows)
--
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] (CASSANDRA-18155) Coordinator level metrics for read response and mutation row and column counts
[ https://issues.apache.org/jira/browse/CASSANDRA-18155 ]
Jon Haddad deleted comment on CASSANDRA-18155:
was (Author: rustyrazorblade):
It would be great if we could include the number of chunks read per request as
part of this patch, would you mind adding that?
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676770#comment-17676770
]
Jon Haddad commented on CASSANDRA-18155:
It would be great if we could include the number of chunks read per request as
part of this patch, would you mind adding that?
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676758#comment-17676758 ] Brandon Williams commented on CASSANDRA-18121: -- Those are already covered by [this|https://github.com/driftx/cassandra/commit/a8e0ad4d068244dc513ea6b93f8bec6eccd8a91a] commit. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676756#comment-17676756 ] Ekaterina Dimitrova commented on CASSANDRA-18121: - Weren't you adding new tests? I would expect for them to have to pop up in HIGHRES too? > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676754#comment-17676754 ] Brandon Williams edited comment on CASSANDRA-18121 at 1/13/23 8:17 PM: --- bq. Just a reminder not to forget to update also the MIDRES and HIGHRES files Updated, though I only had to touch MIDRES in the end. Everything passed except the odd rebuild test failure that I'm working on. was (Author: brandon.williams): > Just a reminder not to forget to update also the MIDRES and HIGHRES files Updated, though I only had to touch MIDRES in the end. Everything passed except the odd rebuild test failure that I'm working on. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676754#comment-17676754 ] Brandon Williams commented on CASSANDRA-18121: -- > Just a reminder not to forget to update also the MIDRES and HIGHRES files Updated, though I only had to touch MIDRES in the end. Everything passed except the odd rebuild test failure that I'm working on. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-17427) Improve unit tests performance
[ https://issues.apache.org/jira/browse/CASSANDRA-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676749#comment-17676749 ] Josh McKenzie commented on CASSANDRA-17427: --- Do I need to re-review this one or were the changes minimal to address that packaging failure? > Improve unit tests performance > -- > > Key: CASSANDRA-17427 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17427 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > There a couple of small improvements to run unit tests a bit faster -- 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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676750#comment-17676750
]
Natnael Adere commented on CASSANDRA-17199:
---
[~bcicchi] I have made some updates to the logging of failed session in a
stream. Currently, I'm cleaning up some test and looking for reviewers. An
example of the a current log output is this:
WARN [node2_Stream-Deserializer-/127.0.0.1:7012-969cebce] node2 2023-01-13
14:06:29,920 StreamResultFuture.java:248 - [Stream
#62ebf140-9375-11ed-80a3-1fe3dc3967e8] Stream failed:
Session peer /127.0.0.1:7012 Failed because there was an
java.nio.channels.ClosedChannelException with state=STREAMING
Any feedback?
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
[
https://issues.apache.org/jira/browse/CASSANDRA-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18155:
Change Category: Operability
Complexity: Normal
Component/s: Observability/Metrics
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Coordinator level metrics for read response and mutation row and column counts
> --
>
> Key: CASSANDRA-18155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> We propose creating a new metric group, {{ClientRequestSize}}, that will
> house 4 new coordinator-level metrics:
> 1.) ColumnsRead - the total number of columns returned from the database to
> clients
> 2.) RowsRead - the total number of rows returned from the database to clients
> 3.) ColumnsWritten - the total number of columns written to the database by
> clients
> 4.) RowsWritten - the total number of rows written to the database by clients
--
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-18155) Coordinator level metrics for read response and mutation row and column counts
Caleb Rackliffe created CASSANDRA-18155:
---
Summary: Coordinator level metrics for read response and mutation
row and column counts
Key: CASSANDRA-18155
URL: https://issues.apache.org/jira/browse/CASSANDRA-18155
Project: Cassandra
Issue Type: Improvement
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
We propose creating a new metric group, {{ClientRequestSize}}, that will house
4 new coordinator-level metrics:
1.) ColumnsRead - the total number of columns returned from the database to
clients
2.) RowsRead - the total number of rows returned from the database to clients
3.) ColumnsWritten - the total number of columns written to the database by
clients
4.) RowsWritten - the total number of rows written to the database by clients
--
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-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676727#comment-17676727 ] Ekaterina Dimitrova edited comment on CASSANDRA-18152 at 1/13/23 6:37 PM: -- Thank you for the ping and the testing, appreciate it! The branch you took is already a bit old and WIP but I think it should serve your needs. I can confirm that I updated some time ago mockito-core to latest version in trunk and that version officially supports Java 17. I haven't used mockito-inline and when I write in Google mockito-inline Java 17 support, it took me to this [page |https://github.com/mockito/mockito/issues/2436] that discusses an issue people reported in 2021 and the maintainers confirming they are testing in CI mockito-inline so _my guess_ is that it should be fine, but I didn't spend too much time in researching. It is important not just to test but also to verify that the maintainers of our dependencies are supporting or planning soon to support newer JDK versions. Hope that helps. was (Author: e.dimitrova): Thank you for the ping and the testing, appreciate it! The branch you took is already a bit old and WIP but I think it should serve your needs. I can confirm that I updated some time ago mockito-core to latest version in trunk and that version officially supports Java 17. I haven't used mockito-inline and when I write in Google mockito-inline Java 17 support, it took me to this page that discusses an issue people reported in 2021 and the maintainers confirming they are testing in CI mockito-inline so _my guess_ is that it should be fine, but I didn't spend too much time in researching. It is important not just to test but also to verify that the maintainers of our dependencies are supporting or planning soon to support newer JDK versions. Hope that helps. > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676727#comment-17676727 ] Ekaterina Dimitrova commented on CASSANDRA-18152: - Thank you for the ping and the testing, appreciate it! The branch you took is already a bit old and WIP but I think it should serve your needs. I can confirm that I updated some time ago mockito-core to latest version in trunk and that version officially supports Java 17. I haven't used mockito-inline and when I write in Google mockito-inline Java 17 support, it took me to this page that discusses an issue people reported in 2021 and the maintainers confirming they are testing in CI mockito-inline so _my guess_ is that it should be fine, but I didn't spend too much time in researching. It is important not just to test but also to verify that the maintainers of our dependencies are supporting or planning soon to support newer JDK versions. Hope that helps. > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676718#comment-17676718 ] David Capwell commented on CASSANDRA-17964: --- bq. The question is if we still want to have the source of that ant task nicely editable / known by IDEA out of the box Since you did it I feel we should keep... there isn't anything wrong with keeping it and is nice to those who use IDEA (the majority of cases)... > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676716#comment-17676716 ] Ekaterina Dimitrova commented on CASSANDRA-18121: - Glad I managed to help. Just a reminder not to forget to update also the MIDRES and HIGHRES files now when you created patches. Thanks > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-17869) Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on jenkins agents
[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676715#comment-17676715
]
Ekaterina Dimitrova commented on CASSANDRA-17869:
-
For the record, while testing both JDK11 and 17 we caught a bug in my branch,
that was fixed. Thanks [~mck]
Things shifted during rebase and I was focused on the Java 17 tests so I didn't
notice earlier.
I left a few questions/comments in the PR but overall it looks good to me!
I think the main question is do we want to commit this now with a toggle that
will switch later when we switch trunk from J8+J11 to J11+J17, or just have it
ready for when the time comes. I leave It up to you Mick to decide. If we
commit it now we will need to test all branches. If we leave it for later, that
also seems ok to me because I do not expect cassandra-builds to get many change
in the meantime.
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> --
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{1}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
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-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676714#comment-17676714 ] David Capwell commented on CASSANDRA-17964: --- [~bereng], [~stefan.miklosovic], I think the issue with removing the annotation is we need to make those tests running and successful... For the *Example tests I think this is fine, maybe it is best we run them always to make sure the examples don't get stale... The *Bench tests will fail 100% of the time in CI... I am in trunk and ran GcCompactionBench, each test takes 1m (will be slower in CI) and each fails... This will have the side effect of adding failing tests and causing the JVM to timeout due to our unit test limit being smaller than the runtime of these tests. So, for the *Bench tests, I think we need a solution other than rename if we drop the annotation... We either do NOT want to run them in CI, or fix (but wouldn't want to put that burden on [~stefan.miklosovic])... Maybe use the @Ignore annotation? I don't like this as it will still take resources in CI, but only 2 files are impacted so prob wouldn't notice the impact > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676687#comment-17676687 ] Brandon Williams edited comment on CASSANDRA-18121 at 1/13/23 5:28 PM: --- Thanks a million! You are correct, and my understanding is that everything passed on the 4G VM because it had more networking resources available, so that mystery is solved. Thanks again! [This|https://github.com/driftx/cassandra/commit/d37046b825691f0d78d557c2ec8488f2114cdb1e] commit should take care of the mid/high patch files bumping the 311 test resources correctly. [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/770/workflows/04f6c81b-6205-438a-9626-5d37ee6ad5a5] goes another smoke test. If this passes I'll make another full attempt on CASSANDRA-18088. was (Author: brandon.williams): Thanks a million! You are correct, and my understanding is that everything passed on the 4G VM because it had more networking resources available, so that mystery is solved. Thanks again! [This|https://github.com/driftx/cassandra/commit/c5f23d3cb29d29d90824b131da035b298650f09b] patch should take care of the mid/high patch files bumping the 311 test resources correctly. [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/769/workflows/93ab2d3a-3ccb-47a8-b66a-0f41aba123dd] goes another smoke test. If this passes I'll make another full attempt on CASSANDRA-18088. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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=17676706#comment-17676706 ] Stefan Miklosovic commented on CASSANDRA-16418: --- I ve commented on this https://github.com/apache/cassandra/pull/2061/files I am +1 on successful build. Comments in the PR are just nits, I leave this to the author's discretion. > 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 > 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-18121) Dtests need python 3.11 support
[ https://issues.apache.org/jira/browse/CASSANDRA-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676687#comment-17676687 ] Brandon Williams commented on CASSANDRA-18121: -- Thanks a million! You are correct, and my understanding is that everything passed on the 4G VM because it had more networking resources available, so that mystery is solved. Thanks again! [This|https://github.com/driftx/cassandra/commit/c5f23d3cb29d29d90824b131da035b298650f09b] patch should take care of the mid/high patch files bumping the 311 test resources correctly. [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/769/workflows/93ab2d3a-3ccb-47a8-b66a-0f41aba123dd] goes another smoke test. If this passes I'll make another full attempt on CASSANDRA-18088. > Dtests need python 3.11 support > --- > > Key: CASSANDRA-18121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18121 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > In order to have cqlsh support 3.11 the dtests also need to support 3.11 so > the cqlsh dtests can be run. -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1767#comment-1767 ] Stefan Miklosovic commented on CASSANDRA-18061: --- OK, his PR is fine. [~maxwellguo] I believe we are almost done! If you address the last few comments around tests. Thank you > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 10h 10m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676661#comment-17676661 ] Mike Adamson commented on CASSANDRA-18058: -- [~maedhroz] [~adelapena] I have completed my changes for both reviews, hopefully covering all requests. Please take another look and let me know if you want any further changes. > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-17698) sstabledump errors when dumping data from index
[
https://issues.apache.org/jira/browse/CASSANDRA-17698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676653#comment-17676653
]
maxwellguo commented on CASSANDRA-17698:
[~blambov][~smiklosovic]
[3.0|https://github.com/apache/cassandra/compare/trunk...Maxwell-Guo:cassandra:CASSANDRA-17698-3.0]
and [~blambov] +1 's patch link
[patch|https://github.com/apache/cassandra/pull/1998]
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...Maxwell-Guo:cassandra:CASSANDRA-17698-3.11]
[4.0|https://github.com/apache/cassandra/compare/cassandra-4.0...Maxwell-Guo:cassandra:CASSANDRA-17698-4.0]
[4.1|https://github.com/apache/cassandra/compare/cassandra-4.1...Maxwell-Guo:cassandra:CASSANDRA-17698-4.1]
[trunk|https://github.com/apache/cassandra/compare/trunk...Maxwell-Guo:cassandra:CASSANDRA-17698-trunk]
java8 precommit :
[trunk|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/381/workflows/abc96440-efcb-46f7-ac80-7610af8982a8]
[4.1|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/382/workflows/014166a5-860e-48f3-a5c0-e7f93810dad8]
[4.0|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/383/workflows/b954f510-75ce-4830-86f4-0f271e8b1b57]
[3.11|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/384/workflows/66938b6e-9a1c-4b62-8505-61e98cedc8e6]
java11 precommit :
[trunk|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/381/workflows/ac333054-47d6-4b9b-a43f-b80904fb8b89]
[4.1|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/382/workflows/2b368971-5aaa-4c98-8eb9-6136b235be45]
[4.0|https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/383/workflows/4baaacad-0933-4ffe-9557-9ca6a985609c]
for my testing resource is limited ,so it may take some time to see the
result.:(
> sstabledump errors when dumping data from index
> ---
>
> Key: CASSANDRA-17698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17698
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Stefan Miklosovic
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> {code:java}
> cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
> cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
> cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
> cqlsh> exit
> ./bin/nodetool flush
> ./tools/bin/sstabledump
> data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db
>
> [
> {
> "partition" : {
> "key" : [ "Joe" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 17,
> "clustering" : [ ] } ] } ]Exception in thread "main"
> java.lang.UnsupportedOperationException
> at
> org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
> at
> org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
> at
> org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
> at
> org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
> at
> org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676637#comment-17676637 ] Jacek Lewandowski commented on CASSANDRA-18061: --- Also I already reviewed today and left some comments on the [~maxwellguo] PR > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h 40m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18152: -- Reviewers: Andres de la Peña > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676636#comment-17676636 ] Jacek Lewandowski commented on CASSANDRA-18061: --- which PR is the current one? > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h 40m > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-17427) Improve unit tests performance
[ https://issues.apache.org/jira/browse/CASSANDRA-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676619#comment-17676619 ] Michael Semb Wever commented on CASSANDRA-17427: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2193/ > Improve unit tests performance > -- > > Key: CASSANDRA-17427 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17427 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > There a couple of small improvements to run unit tests a bit faster -- 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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676611#comment-17676611
]
Andres de la Peña commented on CASSANDRA-18032:
---
Thanks for preparing the patches for the other branches, they seem identical as
expected. I have tested them:
* Without manually specified env vars nor new tests to be automatically
detected.
* With manually specified env vars and without new tests to be automatically
detected.
* Without manually specified env vars and with new tests to be automatically
detected.
* With manually specified env vars and with new tests to be automatically
detected.
In all cases the written env vars are correct and the return code is zero, so
let's commit the proposed fix.
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18032:
--
Status: Ready to Commit (was: Review In Progress)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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-18032) When generate.sh fails its rc=0
[
https://issues.apache.org/jira/browse/CASSANDRA-18032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18032:
--
Reviewers: Andres de la Peña, Berenguer Blasi, Andres de la Peña (was:
Andres de la Peña, Berenguer Blasi)
Andres de la Peña, Berenguer Blasi, Andres de la Peña (was:
Andres de la Peña, Berenguer Blasi)
Status: Review In Progress (was: Patch Available)
> When generate.sh fails its rc=0
> ---
>
> Key: CASSANDRA-18032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18032
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
>
> {code}
> $ ./generate.sh -a
> Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES
> templates from config-2_1.yml
> ./generate.sh: line 171: circleci: command not found
> patching file ./config-2_1.yml
> Hunk #4 succeeded at 1511 (offset 9 lines).
> Hunk #5 succeeded at 1525 (offset 9 lines).
> Hunk #6 succeeded at 1540 (offset 9 lines).
> Hunk #7 succeeded at 1554 (offset 9 lines).
> Hunk #8 succeeded at 1569 (offset 9 lines).
> Hunk #9 succeeded at 1583 (offset 9 lines).
> Hunk #10 succeeded at 1598 (offset 9 lines).
> Hunk #11 succeeded at 1616 (offset 9 lines).
> Hunk #12 succeeded at 1631 (offset 9 lines).
> Hunk #13 succeeded at 1649 (offset 9 lines).
> Hunk #14 succeeded at 1664 (offset 9 lines).
> Hunk #15 succeeded at 1682 (offset 9 lines).
> Hunk #16 succeeded at 1697 (offset 9 lines).
> ./generate.sh: line 177: circleci: command not found
> patching file ./config-2_1.yml
> ./generate.sh: line 183: circleci: command not found
> {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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676599#comment-17676599 ] Stefan Miklosovic commented on CASSANDRA-18061: --- [~jlewandowski] could you review please? I will run the build soonish but it might be reviewed already. > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Status: Patch Available (was: In Progress) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676598#comment-17676598 ] Stefan Miklosovic commented on CASSANDRA-18061: --- Tested and it looks good to me. I put one more commit on top of your work here (1) (just very small cleanup of the code). (1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-18061] (2) [https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18061] > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18061: -- Status: In Progress (was: Changes Suggested) > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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-18146) commons-cli vulnerability: CVE-2021-37533
[ https://issues.apache.org/jira/browse/CASSANDRA-18146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18146: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > commons-cli vulnerability: CVE-2021-37533 > - > > Key: CASSANDRA-18146 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18146 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > This CVE is being reported by the OWASP scan for: > commons-cli-1.1.jar: CVE-2021-37533 > commons-codec-1.9.jar: CVE-2021-37533 > commons-math3-3.2.jar: CVE-2021-37533 > additionally commons-lang3-3.1.jar is also reported on 3.x. -- 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-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=17676583#comment-17676583
]
Stefan Miklosovic edited comment on CASSANDRA-14013 at 1/13/23 11:10 AM:
-
looks great! +1. Lets ship this!
was (Author: smiklosovic):
look great! +1. Lets ship this!
> 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] [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=17676583#comment-17676583
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
look great! +1. Lets ship this!
> 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] [Comment Edited] (CASSANDRA-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[
https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676577#comment-17676577
]
Stefan Miklosovic edited comment on CASSANDRA-18152 at 1/13/23 11:05 AM:
-
I was asked on the mailing list here (0) if this will work with Java 17.
I have verified that it is possible to mock static methods with mockito 4.7.0
and mockito-inline 4.7.0 in Java 17 in this branch (1). This branch is using
the work from CASSANDRA-16895 where I took this branch (2) where upgrade to
Java 17 is done and I rebased it on top of the current trunk. Then, I
cherry-picked the work in (3) on top of this rebased branch with Java 17
support. The cherry-picked commit from CASSANDRA-14361 contains the test which
is using static methods. I was running the test case SimpleSeedProviderTest
which is using mocking of static methods and the test passed.
The branch where the solution to remove the dependency on Mockito in
InternalNodeProbe is here (4) and its build is here (5).
For completeness, without (4) merged, once we use mockito-inline to mock static
methods, these tests fail (6)
Java I was on:
{code:java}
$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
{code}
Letting [~edimitrova] know I did this as well as [~adelapena] that this is
available for review so we are unblocked on CASSANDRA-14361 and I am letting
know [~jlewandowski] that this test was conducted.
(0) https://lists.apache.org/thread/t35wmq90zcfoorjz5dtz6dxt99d5sp6o
(1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-16895-stefan]
(2) [https://github.com/ekaterinadimitrova2/cassandra/tree/16895-trunk-sept]
(3) [https://issues.apache.org/jira/browse/CASSANDRA-14361]
(4) [https://github.com/apache/cassandra/pull/2095]
(5)
[https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18152]
(6)
https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=14361-trunk-review
was (Author: smiklosovic):
I was asked on the mailing list here (0) if this will work with Java 17.
I have verified that it is possible to mock static methods with mockito 4.7.0
and mockito-inline 4.7.0 in Java 17 in this branch (1). This branch is using
the work from CASSANDRA-16895 where I took this branch (2) where upgrade to
Java 17 is done and I rebased it on top of the current trunk. Then, I
cherry-picked the work in (3) on top of this rebased branch with Java 17
support. The cherry-picked commit from CASSANDRA-14361 contains the test which
is using static methods. I was running the test case SimpleSeedProviderTest
which is using mocking of static methods and the test passed.
The branch where the solution to remove the dependency on Mockito in
InternalNodeProbe is here (4) and its build is here (5).
Java I was on:
{code:java}
$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
{code}
Letting [~edimitrova] know I did this as well as [~adelapena] that this is
available for review so we are unblocked on CASSANDRA-14361 and I am letting
know [~jlewandowski] that this test was conducted.
(0) https://lists.apache.org/thread/t35wmq90zcfoorjz5dtz6dxt99d5sp6o
(1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-16895-stefan]
(2) [https://github.com/ekaterinadimitrova2/cassandra/tree/16895-trunk-sept]
(3) [https://issues.apache.org/jira/browse/CASSANDRA-14361]
(4) [https://github.com/apache/cassandra/pull/2095]
(5)
[https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18152]
> mockito-inline causes tests to fail beacause
> o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
> ---
>
> Key: CASSANDRA-18152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18152
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-14361, when we included mockito-inline into the
> build to test the new functionality, unrelated tests in CI started to fail.
> (1)
> This is happening because mockito, together with stuff which enables static
> mocking, just does not play together with our way of doing things in dtest
> framework.
> The workaround is consisting of removing Mockito from InternalNodeProbe, it
> tries to spy on StorageService to not send any notifications back. This might
> be workarounded
[jira] [Comment Edited] (CASSANDRA-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676580#comment-17676580 ] Stefan Miklosovic edited comment on CASSANDRA-18152 at 1/13/23 11:04 AM: - PR: https://github.com/apache/cassandra/pull/2095 builld: https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18152 was (Author: smiklosovic): PR: https://github.com/apache/cassandra/pull/2095 https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18152 > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18152: -- Test and Documentation Plan: CI passes Status: Patch Available (was: In Progress) PR: https://github.com/apache/cassandra/pull/2095 https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18152 > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[
https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676577#comment-17676577
]
Stefan Miklosovic commented on CASSANDRA-18152:
---
I was asked on the mailing list here (0) if this will work with Java 17.
I have verified that it is possible to mock static methods with mockito 4.7.0
and mockito-inline 4.7.0 in Java 17 in this branch (1). This branch is using
the work from CASSANDRA-16895 where I took this branch (2) where upgrade to
Java 17 is done and I rebased it on top of the current trunk. Then, I
cherry-picked the work in (3) on top of this rebased branch with Java 17
support. The cherry-picked commit from CASSANDRA-14361 contains the test which
is using static methods. I was running the test case SimpleSeedProviderTest
which is using mocking of static methods and the test passed.
The branch where the solution to remove the dependency on Mockito in
InternalNodeProbe is here (4) and its build is here (5).
Java I was on:
{code:java}
$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)
{code}
Letting [~edimitrova] know I did this as well as [~adelapena] that this is
available for review so we are unblocked on CASSANDRA-14361 and I am letting
know [~jlewandowski] that this test was conducted.
(0) https://lists.apache.org/thread/t35wmq90zcfoorjz5dtz6dxt99d5sp6o
(1) [https://github.com/instaclustr/cassandra/tree/CASSANDRA-16895-stefan]
(2) [https://github.com/ekaterinadimitrova2/cassandra/tree/16895-trunk-sept]
(3) [https://issues.apache.org/jira/browse/CASSANDRA-14361]
(4) [https://github.com/apache/cassandra/pull/2095]
(5)
[https://app.circleci.com/pipelines/github/instaclustr/cassandra?branch=CASSANDRA-18152]
> mockito-inline causes tests to fail beacause
> o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
> ---
>
> Key: CASSANDRA-18152
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18152
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While working on CASSANDRA-14361, when we included mockito-inline into the
> build to test the new functionality, unrelated tests in CI started to fail.
> (1)
> This is happening because mockito, together with stuff which enables static
> mocking, just does not play together with our way of doing things in dtest
> framework.
> The workaround is consisting of removing Mockito from InternalNodeProbe, it
> tries to spy on StorageService to not send any notifications back. This might
> be workarounded so we do not need Mockito hence tests are fixed and mocking
> of static methods is possible without any other tests failing.
> (1)
> https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink
> see also: [https://github.com/mockito/mockito/issues/2203]
--
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-17427) Improve unit tests performance
[
https://issues.apache.org/jira/browse/CASSANDRA-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676578#comment-17676578
]
Jacek Lewandowski commented on CASSANDRA-17427:
---
Some more comparisons:
{{DescribeStatementTest.describeTest}}, 500 runs on CircleCI: [without a
patch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/452/workflows/4a714ebf-c10c-4bbc-b974-4856c8aafe55/jobs/2732/timing],
[with a
patch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/453/workflows/229135cb-c409-4e44-8169-f9b01092fea0/jobs/2734/timing]
- this shows mostly improvements on initialization and teardown due to
improved cleanup and reduce quiet time periods
{{SSTablesIteratedTest.*}}, 100 runs on CircleCI: [without a
patch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/446/workflows/8d7ec2fe-2d28-490e-aa36-8684dc827a6a/jobs/2721/timing],
[with a
patch|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/450/workflows/85a34177-0659-405d-8727-acf1c9c57d64/jobs/2728/timing]
- this shows mostly improvements related to not flushing schema keyspace on
every change
> Improve unit tests performance
> --
>
> Key: CASSANDRA-17427
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17427
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There a couple of small improvements to run unit tests a bit faster
--
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-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676565#comment-17676565
]
Benedict Elliott Smith commented on CASSANDRA-18125:
The ENOMEM log message only occurs at startup, so if your timeline is correct
this error occurred after your processes first crashed, not before.
Debugging problems like this requires very detailed information, including full
logs and the ability to map table names to specific schema, as well as
information about what queries were being run against the processes. Most of
the data being in one schema is not very helpful information, unfortunately.
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nicolas Henneaux
>Priority: Normal
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> 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}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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-18061) Add compaction type output result for nodetool compactionhistory
[ https://issues.apache.org/jira/browse/CASSANDRA-18061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676552#comment-17676552 ] maxwellguo commented on CASSANDRA-18061: [~smiklosovic] I update the code . pr:https://github.com/apache/cassandra/pull/2047/files#diff-ad515f26e664fe1525daf7c6388fe1a66a853bd389c350cd39c76aed8e121d43R47 and java-8 precommit : https://app.circleci.com/pipelines/github/Maxwell-Guo/cassandra/366/workflows/532a29f6-7a1b-430d-9dd1-f46343c4a037 ut passed. > Add compaction type output result for nodetool compactionhistory > > > Key: CASSANDRA-18061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18061 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Low > Fix For: 4.x > > Time Spent: 9h > Remaining Estimate: 0h > > If we want to see whether we have made a compaction and what kind of > compaction we have done for this node, we may go to see the > compaction_history system table for some deftails or use nodetool > compactionhistory command , But I found that the table do not specify the > compaction type so does the compactionhistory command too, like index build , > compaction type, clean or scrub for this node. So I think may be it is need > to add a type of compaction column to specify the compaction tpe for > system.compaction_history and so we can get the type of compaction through > system.compaction_history table or nodetool compactionhistory to see whether > we have made a major compact for this node .:) -- 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
[cassandra-website] branch asf-staging updated (14c7d9fc -> 723c9a93)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 14c7d9fc generate docs for b072ce0a new 723c9a93 generate docs for b072ce0a This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (14c7d9fc) \ N -- N -- N refs/heads/asf-staging (723c9a93) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17517) In-tree documentation takes a long time to generate
[ https://issues.apache.org/jira/browse/CASSANDRA-17517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676544#comment-17676544 ] Michael Semb Wever commented on CASSANDRA-17517: Just (5) takes a long time, much longer than (4). Addressing this would go a long way. bq. This time could be reduced by downloading the precompiled binaries for branches and tags. There are none for branches. Only for the release tags. If you were able to download binaries, then couldn't we also provide the pre-built docs downloadable? > In-tree documentation takes a long time to generate > --- > > Key: CASSANDRA-17517 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17517 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Anthony Grasso >Assignee: Anthony Grasso >Priority: High > > To generate the in-tree documentation the website-content tooling will > execute the following steps for each branch. > # Copy or clone the Cassandra repository depending on the URL supplied > # Checkout the branch > # Select the version of Java based on the Cassandra version > # Compile Cassandra > # Generate ADOC files for Nodetool and the Cassandra YAML configuration > # Commit to repository > Once the generated ADOC files are committed to the repository, Antora is > executed to generate the HTML. > The majority of the time taken to execute the above steps is in Step 4 where > Cassandra is compiled. This time could be reduced by downloading the > precompiled binaries for branches and tags. -- 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-18152) mockito-inline causes tests to fail beacause o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean
[ https://issues.apache.org/jira/browse/CASSANDRA-18152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18152: -- Bug Category: Parent values: Code(13163) Complexity: Normal Component/s: Test/dtest/java Discovered By: Adhoc Test Fix Version/s: 4.x Severity: Low Assignee: Stefan Miklosovic Status: Open (was: Triage Needed) > mockito-inline causes tests to fail beacause > o.a.c.distributed.mock.nodetool.InternalNodeProbe spies on StorageServiceMBean > --- > > Key: CASSANDRA-18152 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18152 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > While working on CASSANDRA-14361, when we included mockito-inline into the > build to test the new functionality, unrelated tests in CI started to fail. > (1) > This is happening because mockito, together with stuff which enables static > mocking, just does not play together with our way of doing things in dtest > framework. > The workaround is consisting of removing Mockito from InternalNodeProbe, it > tries to spy on StorageService to not send any notifications back. This might > be workarounded so we do not need Mockito hence tests are fixed and mocking > of static methods is possible without any other tests failing. > (1) > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2168/#showFailuresLink > see also: [https://github.com/mockito/mockito/issues/2203] -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676525#comment-17676525 ] Stefan Miklosovic commented on CASSANDRA-14361: --- Introduction of mockito-inline is causing other unrelated tests to fail. The ticket to track the fix of this is CASSANDRA-18152 Unless we find some other way how to test this, this ticket is blocked by CASSANDRA-18152. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ben Bromhead >Assignee: Stefan Miklosovic >Priority: Low > Fix For: 4.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17676520#comment-17676520
]
Nicolas Vollmar commented on CASSANDRA-18125:
-
In our case 4 out of 5 Cassandra crashed one after another within a 2 hour
windows after a couple of months of uptime.
We have ~40 keyspaces with most of the data in Akka Persistence Cassandra
Schema:
[https://doc.akka.io/docs/akka-persistence-cassandra/current/journal.html]
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nicolas Henneaux
>Priority: Normal
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> 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}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {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
