[jira] [Updated] (CASSANDRA-19932) Expose table extensions via schema builders
[ https://issues.apache.org/jira/browse/CASSANDRA-19932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19932: - Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Expose table extensions via schema builders > --- > > Key: CASSANDRA-19932 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > Attachments: AppTest.java > > > Actual need here is to support the ability to specify table-level extensions > via the schema builders. > > *ORIGINAL DESCRIPTION* > CASSANDRA-9426 added the ability to attach an arbitrary map of metadata to > CQL tables. We should add an entry point for this data to TableMetadata in > order to make it accessible to users who wish to make use of this feature. -- 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-19932) Expose table extensions via schema builders
[ https://issues.apache.org/jira/browse/CASSANDRA-19932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19932: - Summary: Expose table extensions via schema builders (was: Expose extensions column on system_schema.tables via TableMetadata) > Expose table extensions via schema builders > --- > > Key: CASSANDRA-19932 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > Attachments: AppTest.java > > > Actual need here is to support the ability to specify table-level extensions > via the schema builders. > > *ORIGINAL DESCRIPTION* > CASSANDRA-9426 added the ability to attach an arbitrary map of metadata to > CQL tables. We should add an entry point for this data to TableMetadata in > order to make it accessible to users who wish to make use of this feature. -- 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-19932) Expose extensions column on system_schema.tables via TableMetadata
[ https://issues.apache.org/jira/browse/CASSANDRA-19932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19932: - Description: Actual need here is to support the ability to specify table-level extensions via the schema builders. *ORIGINAL DESCRIPTION* CASSANDRA-9426 added the ability to attach an arbitrary map of metadata to CQL tables. We should add an entry point for this data to TableMetadata in order to make it accessible to users who wish to make use of this feature. was:[CASSANDRA-9426|https://issues.apache.org/jira/browse/CASSANDRA-9426] added the ability to attach an arbitrary map of metadata to CQL tables. We should add an entry point for this data to TableMetadata in order to make it accessible to users who wish to make use of this feature. > Expose extensions column on system_schema.tables via TableMetadata > -- > > Key: CASSANDRA-19932 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > Attachments: AppTest.java > > > Actual need here is to support the ability to specify table-level extensions > via the schema builders. > > *ORIGINAL DESCRIPTION* > CASSANDRA-9426 added the ability to attach an arbitrary map of metadata to > CQL tables. We should add an entry point for this data to TableMetadata in > order to make it accessible to users who wish to make use of this feature. -- 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-19932) Expose extensions column on system_schema.tables via TableMetadata
[ https://issues.apache.org/jira/browse/CASSANDRA-19932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887484#comment-17887484 ] Bret McGuire commented on CASSANDRA-19932: -- Refactoring this ticket just a bit. After doing a bit of digging it became clear that extensions defined via the mechanism described in CASSANDRA-9426 are already available via driver metadata. Uploaded a sample unit test which demonstrates this fact. Went back to clarify the situation with the user who originally raised this issue; turns out what they're really after is a way to specify options via the schema builders. Updating ticket to reflect this reality. > Expose extensions column on system_schema.tables via TableMetadata > -- > > Key: CASSANDRA-19932 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > Attachments: AppTest.java > > > [CASSANDRA-9426|https://issues.apache.org/jira/browse/CASSANDRA-9426] added > the ability to attach an arbitrary map of metadata to CQL tables. We should > add an entry point for this data to TableMetadata in order to make it > accessible to users who wish to make use of this feature. -- 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-19932) Expose extensions column on system_schema.tables via TableMetadata
[ https://issues.apache.org/jira/browse/CASSANDRA-19932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19932: - Attachment: AppTest.java > Expose extensions column on system_schema.tables via TableMetadata > -- > > Key: CASSANDRA-19932 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > Attachments: AppTest.java > > > [CASSANDRA-9426|https://issues.apache.org/jira/browse/CASSANDRA-9426] added > the ability to attach an arbitrary map of metadata to CQL tables. We should > add an entry point for this data to TableMetadata in order to make it > accessible to users who wish to make use of this feature. -- 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-19930) Query builder support for NOT CQL syntax
[ https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19930: - Source Control Link: https://github.com/apache/cassandra-java-driver/pull/1963 > Query builder support for NOT CQL syntax > > > Key: CASSANDRA-19930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19930 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Bret McGuire >Priority: Normal > > CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a > negation operation for relations. This change looks to be coming for 5.1 > based on > [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and > [this > commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f]. > > We should add support for this construction to the query builder. -- 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-19930) Query builder support for NOT CQL syntax
[ https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19930: - Bug Category: Parent values: Correctness(12982)Level 1 values: API / Semantic Implementation(12988) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Query builder support for NOT CQL syntax > > > Key: CASSANDRA-19930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19930 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Bret McGuire >Priority: Normal > > CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a > negation operation for relations. This change looks to be coming for 5.1 > based on > [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and > [this > commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f]. > > We should add support for this construction to the query builder. -- 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-19930) Query builder support for NOT CQL syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886534#comment-17886534
]
Bret McGuire commented on CASSANDRA-19930:
--
Good news is that the =/!= enhancements don't require any additional operations
here. QueryBuilder already supports these via OngoingSelection.element() (for
choosing what to select) or Relation.mapValue() (for comparisons in a where
clause). The change here is that C* 5.1 will now understand and eval the
query. For example, the following fails in Cassandra 5.0.0:
{noformat}
[cqlsh 6.2.0 | Cassandra 5.0.0 | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> CREATE TABLE foo.bar (a int, b int, c list, d set, e map, PRIMARY KEY (a, b));
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1:
6});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3:
2});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1:
2});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3:
6});
cqlsh> select a from foo.bar where e[1] != 6;
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unsupported "!=" relation: e[1] != 6"
cqlsh> select a from foo.bar where e[1] != 6 allow filtering;
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unsupported "!=" relation: e[1] != 6"{noformat}
> Query builder support for NOT CQL syntax
>
>
> Key: CASSANDRA-19930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19930
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Bret McGuire
>Priority: Normal
>
> CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a
> negation operation for relations. This change looks to be coming for 5.1
> based on
> [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and
> [this
> commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f].
>
> We should add support for this construction to the query builder.
--
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-19930) Query builder support for NOT CQL syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886534#comment-17886534
]
Bret McGuire edited comment on CASSANDRA-19930 at 10/3/24 12:01 AM:
Good news is that the =/!= enhancements don't require any additional operations
here. QueryBuilder already supports these via OngoingSelection.element() (for
choosing what to select) or Relation.mapValue() (for comparisons in a where
clause). The change here is that C* 5.1 will now understand and eval the
query. For example, the following fails in Cassandra 5.0.0:
{noformat}
[cqlsh 6.2.0 | Cassandra 5.0.0 | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> CREATE TABLE foo.bar (a int, b int, c list, d set, e map, PRIMARY KEY (a, b));
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1:
6});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3:
2});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1:
2});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3:
6});
cqlsh> select a from foo.bar where e[1] != 6;
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unsupported "!=" relation: e[1] != 6"
cqlsh> select a from foo.bar where e[1] != 6 allow filtering;
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unsupported "!=" relation: e[1] != 6"{noformat}
Note that these expressions are supported when testing against Cassandra 5.1
above.
was (Author: JIRAUSER304104):
Good news is that the =/!= enhancements don't require any additional operations
here. QueryBuilder already supports these via OngoingSelection.element() (for
choosing what to select) or Relation.mapValue() (for comparisons in a where
clause). The change here is that C* 5.1 will now understand and eval the
query. For example, the following fails in Cassandra 5.0.0:
{noformat}
[cqlsh 6.2.0 | Cassandra 5.0.0 | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> CREATE TABLE foo.bar (a int, b int, c list, d set, e map, PRIMARY KEY (a, b));
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1:
6});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3:
2});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1:
2});
cqlsh> INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3:
6});
cqlsh> select a from foo.bar where e[1] != 6;
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unsupported "!=" relation: e[1] != 6"
cqlsh> select a from foo.bar where e[1] != 6 allow filtering;
InvalidRequest: Error from server: code=2200 [Invalid query]
message="Unsupported "!=" relation: e[1] != 6"{noformat}
> Query builder support for NOT CQL syntax
>
>
> Key: CASSANDRA-19930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19930
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Bret McGuire
>Priority: Normal
>
> CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a
> negation operation for relations. This change looks to be coming for 5.1
> based on
> [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and
> [this
> commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f].
>
> We should add support for this construction to the query builder.
--
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-19930) Query builder support for NOT CQL syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886511#comment-17886511
]
Bret McGuire edited comment on CASSANDRA-19930 at 10/2/24 10:45 PM:
Samples adapted from
[SelectTest.testFilteringWithoutIndicesWithCollections()|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java#L1367]:
{noformat}
CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE foo.bar (a int, b int, c list, d set, e map,
PRIMARY KEY (a, b));
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3: 6});
// And then adding the new tests
// lists
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 AND c NOT CONTAINS 3 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND c NOT CONTAINS 3 ALLOW FILTERING;
// sets
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 AND d NOT CONTAINS 6 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE d CONTAINS 4 AND d NOT CONTAINS 6 ALLOW FILTERING;
// maps
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e NOT CONTAINS KEY 1 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS 2 AND e NOT CONTAINS KEY 1 ALLOW
FILTERING;
// = & != enhancements
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3: 6});
SELECT * FROM foo.bar WHERE e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e[1] != 6 AND e[3] != 2 ALLOW FILTERING; // should
be empty
SELECT * FROM foo.bar WHERE e[1] = 6 AND e[3] = 2 ALLOW FILTERING; // should
be empty
SELECT * FROM foo.bar WHERE e CONTAINS KEY 1 AND e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS KEY 1 AND e NOT CONTAINS 2 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND d CONTAINS 4 AND e NOT CONTAINS
KEY 1 ALLOW FILTERING;
// examples here don’t include NOT IN checks so let’s add a quick check for
that too
SELECT * from foo.bar where a NOT IN (1,2,3); // fails, requires allow filtering
SELECT * from foo.bar where a NOT IN (1,2,3) ALLOW FILTERING; // should be empty
SELECT * from foo.bar where a NOT IN (2,3,4) ALLOW FILTERING;
SELECT * from foo.bar where a NOT IN (4,5,6) ALLOW FILTERING; {noformat}
was (Author: JIRAUSER304104):
Samples adapted from
[SelectTest.testFilteringWithoutIndicesWithCollections()|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java#L1367]:
{noformat}
CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE foo.bar (a int, b int, c list, d set, e map,
PRIMARY KEY (a, b));
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3: 6});
// And then adding the new tests
// lists
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 AND c NOT CONTAINS 3 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND c NOT CONTAINS 3 ALLOW FILTERING;
// sets
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 AND d NOT CONTAINS 6 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE d CONTAINS 4 AND d NOT CONTAINS 6 ALLOW FILTERING;
// maps
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e NOT CONTAINS KEY 1 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS 2 AND e NOT CONTAINS KEY 1 ALLOW
FILTERING;
// = & != enhancements
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1: 6});
[jira] [Commented] (CASSANDRA-19930) Query builder support for NOT CQL syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886511#comment-17886511
]
Bret McGuire commented on CASSANDRA-19930:
--
Samples adapted from
[SelectTest.testFilteringWithoutIndicesWithCollections()|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java#L1367]:
```
CREATE KEYSPACE foo WITH REPLICATION = \{ 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE foo.bar (a int, b int, c list, d set, e map,
PRIMARY KEY (a, b));
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], \{2, 12}, \{1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], \{6, 4}, \{3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], \{2, 4}, \{1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], \{6, 12}, \{3: 6});
// And then adding the new tests
// lists
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 AND c NOT CONTAINS 3 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND c NOT CONTAINS 3 ALLOW FILTERING;
// sets
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 AND d NOT CONTAINS 6 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE d CONTAINS 4 AND d NOT CONTAINS 6 ALLOW FILTERING;
// maps
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e NOT CONTAINS KEY 1 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS 2 AND e NOT CONTAINS KEY 1 ALLOW
FILTERING;
// = & != enhancements
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], \{2, 12}, \{1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], \{6, 4}, \{3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], \{2, 4}, \{1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], \{6, 12}, \{3: 6});
SELECT * FROM foo.bar WHERE e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e[1] != 6 AND e[3] != 2 ALLOW FILTERING; // should
be empty
SELECT * FROM foo.bar WHERE e[1] = 6 AND e[3] = 2 ALLOW FILTERING; // should
be empty
SELECT * FROM foo.bar WHERE e CONTAINS KEY 1 AND e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS KEY 1 AND e NOT CONTAINS 2 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND d CONTAINS 4 AND e NOT CONTAINS
KEY 1 ALLOW FILTERING;
```
> Query builder support for NOT CQL syntax
>
>
> Key: CASSANDRA-19930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19930
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Bret McGuire
>Priority: Normal
>
> CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a
> negation operation for relations. This change looks to be coming for 5.1
> based on
> [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and
> [this
> commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f].
>
> We should add support for this construction to the query builder.
--
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-19930) Query builder support for NOT CQL syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886511#comment-17886511
]
Bret McGuire edited comment on CASSANDRA-19930 at 10/2/24 9:26 PM:
---
Samples adapted from
[SelectTest.testFilteringWithoutIndicesWithCollections()|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java#L1367]:
{noformat}
CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE foo.bar (a int, b int, c list, d set, e map,
PRIMARY KEY (a, b));
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3: 6});
// And then adding the new tests
// lists
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 AND c NOT CONTAINS 3 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND c NOT CONTAINS 3 ALLOW FILTERING;
// sets
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 AND d NOT CONTAINS 6 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE d CONTAINS 4 AND d NOT CONTAINS 6 ALLOW FILTERING;
// maps
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e NOT CONTAINS KEY 1 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS 2 AND e NOT CONTAINS KEY 1 ALLOW
FILTERING;
// = & != enhancements
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], {2, 12}, {1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], {6, 4}, {3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], {2, 4}, {1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], {6, 12}, {3: 6});
SELECT * FROM foo.bar WHERE e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e[1] != 6 AND e[3] != 2 ALLOW FILTERING; // should
be empty
SELECT * FROM foo.bar WHERE e[1] = 6 AND e[3] = 2 ALLOW FILTERING; // should
be empty
SELECT * FROM foo.bar WHERE e CONTAINS KEY 1 AND e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS KEY 1 AND e NOT CONTAINS 2 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND d CONTAINS 4 AND e NOT CONTAINS
KEY 1 ALLOW FILTERING;
{noformat}
was (Author: JIRAUSER304104):
Samples adapted from
[SelectTest.testFilteringWithoutIndicesWithCollections()|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/validation/operations/SelectTest.java#L1367]:
```
CREATE KEYSPACE foo WITH REPLICATION = \{ 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE foo.bar (a int, b int, c list, d set, e map,
PRIMARY KEY (a, b));
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], \{2, 12}, \{1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], \{6, 4}, \{3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], \{2, 4}, \{1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], \{6, 12}, \{3: 6});
// And then adding the new tests
// lists
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE c NOT CONTAINS 2 AND c NOT CONTAINS 3 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE c CONTAINS 2 AND c NOT CONTAINS 3 ALLOW FILTERING;
// sets
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE d NOT CONTAINS 4 AND d NOT CONTAINS 6 ALLOW
FILTERING;
SELECT * FROM foo.bar WHERE d CONTAINS 4 AND d NOT CONTAINS 6 ALLOW FILTERING;
// maps
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2; // fails, requires allow filtering
SELECT * FROM foo.bar WHERE e NOT CONTAINS 2 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e NOT CONTAINS KEY 1 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e CONTAINS 2 AND e NOT CONTAINS KEY 1 ALLOW
FILTERING;
// = & != enhancements
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 2, [1, 6], \{2, 12}, \{1: 6});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 3, [3, 2], \{6, 4}, \{3: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (1, 4, [1, 2], \{2, 4}, \{1: 2});
INSERT INTO foo.bar (a, b, c, d, e) VALUES (2, 3, [3, 6], \{6, 12}, \{3: 6});
SELECT * FROM foo.bar WHERE e[1] != 6 ALLOW FILTERING;
SELECT * FROM foo.bar WHERE e[1] != 6 AND e[3]
[jira] [Commented] (CASSANDRA-19930) Query builder support for NOT CQL syntax
[ https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886500#comment-17886500 ] Bret McGuire commented on CASSANDRA-19930: -- Lots of details in [CEP-29|[https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator].] Based on what's described there we'll be adding support for NOT IN, NOT CONTAINS and NOT CONTAINS KEY to the query builder. Based on [comments on CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584?focusedCommentId=17752083&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17752083] we will not be adding support for NOT LIKE as part of this ticket. This PR also appears to [extend the areas in which = and != may be used|https://issues.apache.org/jira/browse/CASSANDRA-18584?focusedCommentId=17877916&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17877916]. There may be some additional work to add this support; I'll know more once I dig into it. > Query builder support for NOT CQL syntax > > > Key: CASSANDRA-19930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19930 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Bret McGuire >Priority: Normal > > CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a > negation operation for relations. This change looks to be coming for 5.1 > based on > [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and > [this > commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f]. > > We should add support for this construction to the query builder. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19930) Query builder support for NOT CQL syntax
[ https://issues.apache.org/jira/browse/CASSANDRA-19930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire reassigned CASSANDRA-19930: Assignee: Bret McGuire > Query builder support for NOT CQL syntax > > > Key: CASSANDRA-19930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19930 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Bret McGuire >Priority: Normal > > CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a > negation operation for relations. This change looks to be coming for 5.1 > based on > [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and > [this > commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f]. > > We should add support for this construction to the query builder. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19932) Expose extensions column on system_schema.tables via TableMetadata
[ https://issues.apache.org/jira/browse/CASSANDRA-19932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire reassigned CASSANDRA-19932: Assignee: Lukasz Antoniak > Expose extensions column on system_schema.tables via TableMetadata > -- > > Key: CASSANDRA-19932 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > > [CASSANDRA-9426|https://issues.apache.org/jira/browse/CASSANDRA-9426] added > the ability to attach an arbitrary map of metadata to CQL tables. We should > add an entry point for this data to TableMetadata in order to make it > accessible to users who wish to make use of this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19931) Query builder support for OR syntax in where clauses
[ https://issues.apache.org/jira/browse/CASSANDRA-19931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire reassigned CASSANDRA-19931: Assignee: Lukasz Antoniak > Query builder support for OR syntax in where clauses > > > Key: CASSANDRA-19931 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19931 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Bret McGuire >Assignee: Lukasz Antoniak >Priority: Normal > > Query builder currently supports combining relations via the AND keyword by > adding multiple relations using OngoingWhereClause.where(). There's no > ability to combine relations using the OR keyword, however. > > Ideally we'd implement a fairly flexible API (possibly off of Relation > itself) which allows users to construct complex compound relations using AND > and/or OR which can then be added to the set of relations for an > OngoingWhereClause. -- 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-19932) Expose extensions column on system_schema.tables via TableMetadata
Bret McGuire created CASSANDRA-19932: Summary: Expose extensions column on system_schema.tables via TableMetadata Key: CASSANDRA-19932 URL: https://issues.apache.org/jira/browse/CASSANDRA-19932 Project: Cassandra Issue Type: Improvement Components: Client/java-driver Reporter: Bret McGuire [CASSANDRA-9426|https://issues.apache.org/jira/browse/CASSANDRA-9426] added the ability to attach an arbitrary map of metadata to CQL tables. We should add an entry point for this data to TableMetadata in order to make it accessible to users who wish to make use of this feature. -- 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-19931) Query builder support for OR syntax in where clauses
Bret McGuire created CASSANDRA-19931: Summary: Query builder support for OR syntax in where clauses Key: CASSANDRA-19931 URL: https://issues.apache.org/jira/browse/CASSANDRA-19931 Project: Cassandra Issue Type: Improvement Components: Client/java-driver Reporter: Bret McGuire Query builder currently supports combining relations via the AND keyword by adding multiple relations using OngoingWhereClause.where(). There's no ability to combine relations using the OR keyword, however. Ideally we'd implement a fairly flexible API (possibly off of Relation itself) which allows users to construct complex compound relations using AND and/or OR which can then be added to the set of relations for an OngoingWhereClause. -- 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-19930) Query builder support for NOT CQL syntax
Bret McGuire created CASSANDRA-19930: Summary: Query builder support for NOT CQL syntax Key: CASSANDRA-19930 URL: https://issues.apache.org/jira/browse/CASSANDRA-19930 Project: Cassandra Issue Type: Bug Components: Client/java-driver Reporter: Bret McGuire CEP-29 describes a CQL syntax enhancement to support the NOT keyword as a negation operation for relations. This change looks to be coming for 5.1 based on [CASSANDRA-18584|https://issues.apache.org/jira/browse/CASSANDRA-18584] and [this commit|https://github.com/apache/cassandra/commit/e0074a31ef26adaebff6ac0657e4471fc805f93f]. We should add support for this construction to the query builder. -- 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-19913) Add vectors to "should we invalidate" checks for PS cache
[ https://issues.apache.org/jira/browse/CASSANDRA-19913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19913: - Description: [JAVA-3058|https://datastax-oss.atlassian.net/browse/JAVA-3058] introduced additional checks to the prepared statement cache invalidation logic to invalidate prepared statements using various collection types of types that have bene altered. This logic evaluates subtypes for UDTs, tuples and the various collection types (list, map and set). We should add similar checks for vectors. If a vector type A is altered and we have a prepared statement in the cache with a param type of vector (for some integer N) that statement should be invalidated. was: JAVA-3058 introduced additional checks to the prepared statement cache invalidation logic to invalidate prepared statements using various collection types of types that have bene altered. This logic evaluates subtypes for UDTs, tuples and the various collection types (list, map and set). We should add similar checks for vectors. If a vector type A is altered and we have a prepared statement in the cache with a param type of vector (for some integer N) that statement should be invalidated. > Add vectors to "should we invalidate" checks for PS cache > - > > Key: CASSANDRA-19913 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19913 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Priority: Normal > > [JAVA-3058|https://datastax-oss.atlassian.net/browse/JAVA-3058] introduced > additional checks to the prepared statement cache invalidation logic to > invalidate prepared statements using various collection types of types that > have bene altered. This logic evaluates subtypes for UDTs, tuples and the > various collection types (list, map and set). > > We should add similar checks for vectors. If a vector type A is altered and > we have a prepared statement in the cache with a param type of vector > (for some integer N) that statement should be invalidated. -- 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-19913) Add vectors to "should we invalidate" checks for PS cache
Bret McGuire created CASSANDRA-19913: Summary: Add vectors to "should we invalidate" checks for PS cache Key: CASSANDRA-19913 URL: https://issues.apache.org/jira/browse/CASSANDRA-19913 Project: Cassandra Issue Type: Bug Components: Client/java-driver Reporter: Bret McGuire JAVA-3058 introduced additional checks to the prepared statement cache invalidation logic to invalidate prepared statements using various collection types of types that have bene altered. This logic evaluates subtypes for UDTs, tuples and the various collection types (list, map and set). We should add similar checks for vectors. If a vector type A is altered and we have a prepared statement in the cache with a param type of vector (for some integer N) that statement should be invalidated. -- 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-19796) Setup cassandra-gocql-driver CI
[ https://issues.apache.org/jira/browse/CASSANDRA-19796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879630#comment-17879630 ] Bret McGuire commented on CASSANDRA-19796: -- Mentioned on the PR for this ticket but I'll mention it here as well; I'm already looking at updating the Go versions we test against to 1.22 and 1.23 for the 1.7.0 release [here|https://github.com/apache/cassandra-gocql-driver/pull/1813]. I'm trying to make 1.7.0 as small as possible so I don't want to pull in any of the other changes in the [working PR|https://github.com/apache/cassandra-gocql-driver/pull/1812] for this ticket. > Setup cassandra-gocql-driver CI > --- > > Key: CASSANDRA-19796 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19796 > Project: Cassandra > Issue Type: Sub-task > Components: CI, Client/gocql-driver >Reporter: Michael Semb Wever >Assignee: Stanislav Bychkov >Priority: Normal > Time Spent: 2h 50m > Remaining Estimate: 0h > > This may be just confirming GHA still works. -- 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-19837) QueryBuilder Select does not support new vector sort syntax
[
https://issues.apache.org/jira/browse/CASSANDRA-19837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874902#comment-17874902
]
Bret McGuire commented on CASSANDRA-19837:
--
Good news [~mp911de] : this is being addressed as part of work being done on
[JAVA-3118|https://datastax-oss.atlassian.net/browse/JAVA-3118]!
> QueryBuilder Select does not support new vector sort syntax
> ---
>
> Key: CASSANDRA-19837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19837
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Mark Paluch
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Building Select statements through
> {{com.datastax.oss.driver.api.querybuilder.select.Select}} only supports
> ASC/DESC ordering and not {{ORDER BY … ANN OF ….}}
>
> It would be good to have the vector search syntax in the query builder for
> all users that rely on the Query Builder. This extension should also accept
> {{Term}} to be able to bind vector values.
--
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-19584) Glossary labeled as DataStax glossary
[ https://issues.apache.org/jira/browse/CASSANDRA-19584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17866433#comment-17866433 ] Bret McGuire commented on CASSANDRA-19584: -- +1 from me as well. Thanks [~bschoeni]! > Glossary labeled as DataStax glossary > - > > Key: CASSANDRA-19584 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19584 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Jon Haddad >Assignee: Brad Schoening >Priority: Normal > Attachments: screenshot-1.png > > > Should be Cassandra glossary > https://cassandra.apache.org/_/glossary.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19678) Start testing Java driver against Java21
Bret McGuire created CASSANDRA-19678: Summary: Start testing Java driver against Java21 Key: CASSANDRA-19678 URL: https://issues.apache.org/jira/browse/CASSANDRA-19678 Project: Cassandra Issue Type: Task Components: Client/java-driver Reporter: Bret McGuire We have a new LTS out... should probably look at including it in the test matrix (or at least validating it's behaviour). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19635) Update target Cassandra versions for integration tests, support new 5.0.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19635:
-
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> Update target Cassandra versions for integration tests, support new 5.0.x
> -
>
> Key: CASSANDRA-19635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19635
> Project: Cassandra
> Issue Type: Task
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Lukasz Antoniak
>Priority: Normal
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> {color:#172b4d}[CASSANDRA-19292|https://issues.apache.org/jira/browse/CASSANDRA-19292]
> added support for running integration tests against Cassandra 4.1.x but we
> still need the ability to run against Cassandra 5.0.x. As of this writing we
> need [riptano/ccm|https://github.com/riptano/ccm] to manage Cassandra 5.0.x
> clusters. The DataStax CI infrastructure, however, uses a private fork of
> ccm which adds the ability to manage DSE clusters (something riptano/ccm
> can't do right now). So we presumably need to do one of the following:
> {color}
> * Port Cassandra 5.0.x support to the private fork
> * Port DSE support to riptano/ccm
> * Change the build process to install both riptano/ccm and the private fork
> into distinct venvs and manage accordingly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19635) Update target Cassandra versions for integration tests, support new 5.0.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire reassigned CASSANDRA-19635:
Assignee: Lukasz Antoniak (was: Shiva Kalyan)
> Update target Cassandra versions for integration tests, support new 5.0.x
> -
>
> Key: CASSANDRA-19635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19635
> Project: Cassandra
> Issue Type: Task
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Lukasz Antoniak
>Priority: Normal
> Time Spent: 3h
> Remaining Estimate: 0h
>
> {color:#172b4d}[CASSANDRA-19292|https://issues.apache.org/jira/browse/CASSANDRA-19292]
> added support for running integration tests against Cassandra 4.1.x but we
> still need the ability to run against Cassandra 5.0.x. As of this writing we
> need [riptano/ccm|https://github.com/riptano/ccm] to manage Cassandra 5.0.x
> clusters. The DataStax CI infrastructure, however, uses a private fork of
> ccm which adds the ability to manage DSE clusters (something riptano/ccm
> can't do right now). So we presumably need to do one of the following:
> {color}
> * Port Cassandra 5.0.x support to the private fork
> * Port DSE support to riptano/ccm
> * Change the build process to install both riptano/ccm and the private fork
> into distinct venvs and manage accordingly
--
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-19662) Data Corruption and OOM Issues During Schema Alterations
[
https://issues.apache.org/jira/browse/CASSANDRA-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850142#comment-17850142
]
Bret McGuire commented on CASSANDRA-19662:
--
Just to clarify a few things here [~kumarbharath]:
# You mentioned "select *" statements were in use for reads. Am I correct in
saying those "select *" statements are implemented using prepared statements?
# Do we know the protocol version in use for this client + server? The
behaviour described above sounds a lot like what you'd expect to see before
CASSANDRA-10786 came into play but the changes implemented there should be in
place for Cassandra 4.0.12 and Java driver 4.17.0. That said, they also still
rely on protocol v5 features to function correctly... so if a different
protocol is specified you won't get the error correcting behaviour in 10786.
> Data Corruption and OOM Issues During Schema Alterations
> -
>
> Key: CASSANDRA-19662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19662
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: BHARATH KUMAR
>Priority: Urgent
> Attachments: BufferUnderflow_plus_error
>
>
> h2. Description
>
> *Overview:* The primary issue is data corruption occurring during schema
> alterations (ADD/DROP column) on large tables(300+ columns and 6TB size ) in
> the production cluster. This is accompanied by out-of-memory (OOM) errors and
> other exceptions, specifically during batch reads. This problem has been
> replicated on multiple clusters, running Apache Cassandra version 4.0.12 and
> Datastax Java Driver Version: 4.17
> *Details:*
> *Main Issue:*
> * *Data Corruption:* When dynamically adding a column to a table, the data
> intended for the new column is shifted, causing misalignment in the data.
> * *Symptoms:* The object implementing
> {{com.datastax.oss.driver.api.core.cql.Row}} returns values shifted against
> the column names returned by {{{}row.getColumnDefinitions(){}}}. The driver
> returns a corrupted row, leading to incorrect data insertion.
> *Additional Issues:*
> *Exceptions:*
> * {{java.nio.BufferUnderflowException}} during batch reads when ALTER TABLE
> ADD/DROP column statements are issued.
> * {{java.lang.ArrayIndexOutOfBoundsException}} in some cases.
> * Buffer underflow exceptions with messages like "Invalid 32-bits integer
> value, expecting 4 bytes but got 292".
> * OOM errors mostly occur during ADD column operations, while other
> exceptions occur during DELETE column operations.
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> *Reproducibility:*
> * The issue is reproducible on larger tables (300 columns, 6 TB size) but
> not on smaller tables.
> * SELECT * statements are used during reads
> * *Method Specific:* Errors occur specifically with
> {{{}row.getList(columnName, Float.class){}}}, returning incorrect values.
> However, the code registers a driver exception when calling the method
> {{{}row.getList(columnName, Float.class){}}}. We pass the exact column name
> obtained from {{{}row.getColumnDefinition{}}}, but it returns the wrong value
> for a column with this name. This suggests that the issue lies with the
> driver returning an object with incorrect properties, rather than with the
> SQL query itself.
> *Debugging Efforts:*
> * *Metadata Refresh:* Enabling metadata refresh did not resolve the issue.
> * *Schema Agreement:* {{session.getCqlSession().checkSchemaAgreement()}} did
> not detect inconsistencies during test execution.
--
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-19665) Add download link for Java drivers from download page
Bret McGuire created CASSANDRA-19665: Summary: Add download link for Java drivers from download page Key: CASSANDRA-19665 URL: https://issues.apache.org/jira/browse/CASSANDRA-19665 Project: Cassandra Issue Type: Task Components: Client/java-driver, Documentation/Website Reporter: Bret McGuire Seems like we should have a link to download Java drivers from the [download page|https://cassandra.apache.org/_/download.html] on the Website -- 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-19451) An Option of Latency Sensitive Load Balancing Policy
[ https://issues.apache.org/jira/browse/CASSANDRA-19451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19451: - Resolution: Won't Fix Status: Resolved (was: Triage Needed) > An Option of Latency Sensitive Load Balancing Policy > > > Key: CASSANDRA-19451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19451 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: High > Time Spent: 40m > Remaining Estimate: 0h > > We have received concerns from the community about the 4.x java driver > default load balancing policy's performance in terms of busy node avoidance. > In some circumstances, when some nodes are busy, the 3.x java driver's > `LatencyAwarenessLoadBalancingPolicy` almost does not send requests to the > busy nodes, while the 4.x default one will still send a lot of requests to > them. This is because the 4.x default one uses in-flight count and responses > in the past 200ms to determine a node's health instead of latency. > Therefore, we want to create another class called > `LatencySensitiveLoadBalancingPolicy` in the 4.x java driver, which will > combine the in-flight count and the latency. A user can use it by specifying > it in `application.conf`. -- 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-19451) An Option of Latency Sensitive Load Balancing Policy
[ https://issues.apache.org/jira/browse/CASSANDRA-19451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849404#comment-17849404 ] Bret McGuire commented on CASSANDRA-19451: -- To close the loop here: we wound up releasing this as a [separate artifact|https://github.com/datastax/java-driver-policies] managed by DataStax. We saw real problems with the plethora of options users had with the 3.x Java driver; the explosion of combinations of LBPs in that driver led to confusion about what should be used in what situations. 4.x very deliberately went the other way by maintaining a single LBP (DefaultLoadBalancingPolicy) which has very reasonable behaviour in a wide range of configurations. To avoid re-introducing the confusion we saw with 3.x the aim here is to keep extraneous LBPs out of the core driver and in discrete artifacts. We can consider addressing this in the future via something like the "extras" directory maintained in the 3.x driver. The 4.x driver has an "examples" directory which serves a similar function but it's not exactly equivalent. Furthermore any such optional policy should have _very_ clear guidance around it's behaviour and in what cases a user may want to consider deploying it. > An Option of Latency Sensitive Load Balancing Policy > > > Key: CASSANDRA-19451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19451 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: High > Time Spent: 40m > Remaining Estimate: 0h > > We have received concerns from the community about the 4.x java driver > default load balancing policy's performance in terms of busy node avoidance. > In some circumstances, when some nodes are busy, the 3.x java driver's > `LatencyAwarenessLoadBalancingPolicy` almost does not send requests to the > busy nodes, while the 4.x default one will still send a lot of requests to > them. This is because the 4.x default one uses in-flight count and responses > in the past 200ms to determine a node's health instead of latency. > Therefore, we want to create another class called > `LatencySensitiveLoadBalancingPolicy` in the 4.x java driver, which will > combine the in-flight count and the latency. A user can use it by specifying > it in `application.conf`. -- 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-19635) Update target Cassandra versions for integration tests, support new 5.0.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17848669#comment-17848669
]
Bret McGuire commented on CASSANDRA-19635:
--
An additional note here: there's an interesting goal to add support for running
tests against current C* master, which at the moment would be the "tip of the
spear" of Cassandra 5.0 development. While this is a useful feature to add
it's (a) secondary to the immediate concern about validating the Java driver
against Cassandra 5.0.x and (b) something that should live in any CI
infrastructure built for the ASF (CASSANDRA-18971) rather than something we add
to the legacy DataStax infrastructure.
> Update target Cassandra versions for integration tests, support new 5.0.x
> -
>
> Key: CASSANDRA-19635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19635
> Project: Cassandra
> Issue Type: Task
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Shiva Kalyan
>Priority: Normal
>
> {color:#172b4d}[CASSANDRA-19292|https://issues.apache.org/jira/browse/CASSANDRA-19292]
> added support for running integration tests against Cassandra 4.1.x but we
> still need the ability to run against Cassandra 5.0.x. As of this writing we
> need [riptano/ccm|https://github.com/riptano/ccm] to manage Cassandra 5.0.x
> clusters. The DataStax CI infrastructure, however, uses a private fork of
> ccm which adds the ability to manage DSE clusters (something riptano/ccm
> can't do right now). So we presumably need to do one of the following:
> {color}
> * Port Cassandra 5.0.x support to the private fork
> * Port DSE support to riptano/ccm
> * Change the build process to install both riptano/ccm and the private fork
> into distinct venvs and manage accordingly
--
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-19649) add absurdfarce's gpg key to project's KEYS file
Bret McGuire created CASSANDRA-19649: Summary: add absurdfarce's gpg key to project's KEYS file Key: CASSANDRA-19649 URL: https://issues.apache.org/jira/browse/CASSANDRA-19649 Project: Cassandra Issue Type: Task Components: Packaging Reporter: Bret McGuire Attachments: absurdfarce_keys.patch The patch adds my gpg public key to the project's KEYS file found at [https://dist.apache.org/repos/dist/release/cassandra/KEYS] My gpg public key here has the fingerprint 498AAC354AA5CB36FAAB7608B6E83A2D2E447E56 References: - [https://www.apache.org/dev/release-signing#keys-policy] - [http://www.apache.org/legal/release-policy.html] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19635) Update target Cassandra versions for integration tests, support new 5.0.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846744#comment-17846744
]
Bret McGuire commented on CASSANDRA-19635:
--
Of relevance here: there's an [ongoing
conversation|https://lists.apache.org/thread/y3xfkypd7v2n3xmp9b75ob1c6xngo572]
around bringing ccm in as a subproject of the Cassandra project.
> Update target Cassandra versions for integration tests, support new 5.0.x
> -
>
> Key: CASSANDRA-19635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19635
> Project: Cassandra
> Issue Type: Task
> Components: Client/java-driver
>Reporter: Bret McGuire
>Priority: Normal
>
> {color:#172b4d}[CASSANDRA-19292|https://issues.apache.org/jira/browse/CASSANDRA-19292]
> added support for running integration tests against Cassandra 4.1.x but we
> still need the ability to run against Cassandra 5.0.x. As of this writing we
> need [riptano/ccm|https://github.com/riptano/ccm] to manage Cassandra 5.0.x
> clusters. The DataStax CI infrastructure, however, uses a private fork of
> ccm which adds the ability to manage DSE clusters (something riptano/ccm
> can't do right now). So we presumably need to do one of the following:
> {color}
> * Port Cassandra 5.0.x support to the private fork
> * Port DSE support to riptano/ccm
> * Change the build process to install both riptano/ccm and the private fork
> into distinct venvs and manage accordingly
--
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-19635) Update target Cassandra versions for integration tests, support new 5.0.x
Bret McGuire created CASSANDRA-19635:
Summary: Update target Cassandra versions for integration tests,
support new 5.0.x
Key: CASSANDRA-19635
URL: https://issues.apache.org/jira/browse/CASSANDRA-19635
Project: Cassandra
Issue Type: Task
Components: Client/java-driver
Reporter: Bret McGuire
{color:#172b4d}[CASSANDRA-19292|https://issues.apache.org/jira/browse/CASSANDRA-19292]
added support for running integration tests against Cassandra 4.1.x but we
still need the ability to run against Cassandra 5.0.x. As of this writing we
need [riptano/ccm|https://github.com/riptano/ccm] to manage Cassandra 5.0.x
clusters. The DataStax CI infrastructure, however, uses a private fork of ccm
which adds the ability to manage DSE clusters (something riptano/ccm can't do
right now). So we presumably need to do one of the following:
{color}
* Port Cassandra 5.0.x support to the private fork
* Port DSE support to riptano/ccm
* Change the build process to install both riptano/ccm and the private fork
into distinct venvs and manage accordingly
--
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-19630) Intermittent test failures for com.datastax.oss.driver.metrics.microprofile.MicroProfileMetricsIT.should_evict_down_node_metrics_when_timeout_fires
[
https://issues.apache.org/jira/browse/CASSANDRA-19630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845056#comment-17845056
]
Bret McGuire commented on CASSANDRA-19630:
--
Haven't dug into this in great detail but this looks to be another
timing-related issue. The [test method in
question|https://github.com/apache/cassandra-java-driver/blob/4.x/integration-tests/src/test/java/com/datastax/oss/driver/core/metrics/MetricsITBase.java#L172-L183]
sends a "node down" event over the EventBus, waits for the specified duration
time and then immediately checks to see if the metric has been removal.
There's no accounting here for possible delays in delivery (or any other kind
of delay).
> Intermittent test failures for
> com.datastax.oss.driver.metrics.microprofile.MicroProfileMetricsIT.should_evict_down_node_metrics_when_timeout_fires
> ---
>
> Key: CASSANDRA-19630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19630
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Priority: Normal
>
> Observed on a couple different Jenkins runs. Failure on first run was
> against Java8/Cassandra 4.1 (other combinations were fine), failure on second
> run was against Java11/Cassandra 4.1 (again other combinations were fine).
>
> Representative stack trace:
> {code:java}
> Assertion condition defined as a lambda expression in
> com.datastax.oss.driver.core.metrics.MetricsITBase
> Expecting:
> {MetricID{name='s289.bytes-received',
> tags=[]}=io.smallrye.metrics.app.MeterImpl@5a070350,
> MetricID{name='s289.bytes-sent',
> tags=[]}=io.smallrye.metrics.app.MeterImpl@74ab40b6,
> MetricID{name='s289.connected-nodes',
> tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileSessionMetricUpdater$$Lambda$1092/0x0008007f2440@4310e1a6,
> MetricID{name='s289.cql-client-timeouts',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@973bf98,
> MetricID{name='s289.cql-prepared-cache-size',
> tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileSessionMetricUpdater$$Lambda$1096/0x0008007f7840@6b0c2065,
> MetricID{name='s289.cql-requests',
> tags=[]}=io.smallrye.metrics.app.TimerImpl@458c7342,
> MetricID{name='s289.nodes.127_0_0_130:9043.bytes-received',
> tags=[]}=io.smallrye.metrics.app.MeterImpl@155b784,
> MetricID{name='s289.nodes.127_0_0_130:9043.bytes-sent',
> tags=[]}=io.smallrye.metrics.app.MeterImpl@154e5749,
> MetricID{name='s289.nodes.127_0_0_130:9043.cql-messages',
> tags=[]}=io.smallrye.metrics.app.TimerImpl@1f4b528d,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.connection.auth',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@397b2445,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.connection.init',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@15be5d79,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.aborted',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@722db498,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.others',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@37b75f6a,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.read-timeouts',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@570e0cd5,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.unavailables',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@30bcd6d8,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.unsent',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@2f2a2d23,
> MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.write-timeouts',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@22eb6ba3,
> MetricID{name='s289.nodes.127_0_0_130:9043.ignores.aborted',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@524b38f,
> MetricID{name='s289.nodes.127_0_0_130:9043.ignores.other',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@53f8afe5,
> MetricID{name='s289.nodes.127_0_0_130:9043.ignores.read-timeout',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@2dc5c38c,
> MetricID{name='s289.nodes.127_0_0_130:9043.ignores.total',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@548a13e4,
> MetricID{name='s289.nodes.127_0_0_130:9043.ignores.unavailable',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@74126a31,
> MetricID{name='s289.nodes.127_0_0_130:9043.ignores.write-timeout',
> tags=[]}=io.smallrye.metrics.app.CounterImpl@628364d1,
> MetricID{name='s289.nodes.127_0_0_130:9043.pool.available-streams',
> tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileNodeMetricUpdater$$Lambda$1117/0x000800809040@61d912ae,
> MetricID{name='s289.nodes.127_0_0_130:9043.pool.in-flight',
> tags=[]}=com.datastax.oss.driver.internal
[jira] [Created] (CASSANDRA-19630) Intermittent test failures for com.datastax.oss.driver.metrics.microprofile.MicroProfileMetricsIT.should_evict_down_node_metrics_when_timeout_fires
Bret McGuire created CASSANDRA-19630:
Summary: Intermittent test failures for
com.datastax.oss.driver.metrics.microprofile.MicroProfileMetricsIT.should_evict_down_node_metrics_when_timeout_fires
Key: CASSANDRA-19630
URL: https://issues.apache.org/jira/browse/CASSANDRA-19630
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Bret McGuire
Observed on a couple different Jenkins runs. Failure on first run was against
Java8/Cassandra 4.1 (other combinations were fine), failure on second run was
against Java11/Cassandra 4.1 (again other combinations were fine).
Representative stack trace:
{code:java}
Assertion condition defined as a lambda expression in
com.datastax.oss.driver.core.metrics.MetricsITBase
Expecting:
{MetricID{name='s289.bytes-received',
tags=[]}=io.smallrye.metrics.app.MeterImpl@5a070350,
MetricID{name='s289.bytes-sent',
tags=[]}=io.smallrye.metrics.app.MeterImpl@74ab40b6,
MetricID{name='s289.connected-nodes',
tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileSessionMetricUpdater$$Lambda$1092/0x0008007f2440@4310e1a6,
MetricID{name='s289.cql-client-timeouts',
tags=[]}=io.smallrye.metrics.app.CounterImpl@973bf98,
MetricID{name='s289.cql-prepared-cache-size',
tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileSessionMetricUpdater$$Lambda$1096/0x0008007f7840@6b0c2065,
MetricID{name='s289.cql-requests',
tags=[]}=io.smallrye.metrics.app.TimerImpl@458c7342,
MetricID{name='s289.nodes.127_0_0_130:9043.bytes-received',
tags=[]}=io.smallrye.metrics.app.MeterImpl@155b784,
MetricID{name='s289.nodes.127_0_0_130:9043.bytes-sent',
tags=[]}=io.smallrye.metrics.app.MeterImpl@154e5749,
MetricID{name='s289.nodes.127_0_0_130:9043.cql-messages',
tags=[]}=io.smallrye.metrics.app.TimerImpl@1f4b528d,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.connection.auth',
tags=[]}=io.smallrye.metrics.app.CounterImpl@397b2445,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.connection.init',
tags=[]}=io.smallrye.metrics.app.CounterImpl@15be5d79,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.aborted',
tags=[]}=io.smallrye.metrics.app.CounterImpl@722db498,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.others',
tags=[]}=io.smallrye.metrics.app.CounterImpl@37b75f6a,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.read-timeouts',
tags=[]}=io.smallrye.metrics.app.CounterImpl@570e0cd5,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.unavailables',
tags=[]}=io.smallrye.metrics.app.CounterImpl@30bcd6d8,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.unsent',
tags=[]}=io.smallrye.metrics.app.CounterImpl@2f2a2d23,
MetricID{name='s289.nodes.127_0_0_130:9043.errors.request.write-timeouts',
tags=[]}=io.smallrye.metrics.app.CounterImpl@22eb6ba3,
MetricID{name='s289.nodes.127_0_0_130:9043.ignores.aborted',
tags=[]}=io.smallrye.metrics.app.CounterImpl@524b38f,
MetricID{name='s289.nodes.127_0_0_130:9043.ignores.other',
tags=[]}=io.smallrye.metrics.app.CounterImpl@53f8afe5,
MetricID{name='s289.nodes.127_0_0_130:9043.ignores.read-timeout',
tags=[]}=io.smallrye.metrics.app.CounterImpl@2dc5c38c,
MetricID{name='s289.nodes.127_0_0_130:9043.ignores.total',
tags=[]}=io.smallrye.metrics.app.CounterImpl@548a13e4,
MetricID{name='s289.nodes.127_0_0_130:9043.ignores.unavailable',
tags=[]}=io.smallrye.metrics.app.CounterImpl@74126a31,
MetricID{name='s289.nodes.127_0_0_130:9043.ignores.write-timeout',
tags=[]}=io.smallrye.metrics.app.CounterImpl@628364d1,
MetricID{name='s289.nodes.127_0_0_130:9043.pool.available-streams',
tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileNodeMetricUpdater$$Lambda$1117/0x000800809040@61d912ae,
MetricID{name='s289.nodes.127_0_0_130:9043.pool.in-flight',
tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileNodeMetricUpdater$$Lambda$1118/0x000800809440@65c82842,
MetricID{name='s289.nodes.127_0_0_130:9043.pool.open-connections',
tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileNodeMetricUpdater$$Lambda$1114/0x000800808040@26c9528,
MetricID{name='s289.nodes.127_0_0_130:9043.pool.orphaned-streams',
tags=[]}=com.datastax.oss.driver.internal.metrics.microprofile.MicroProfileNodeMetricUpdater$$Lambda$1119/0x000800809840@7bb0dc58,
MetricID{name='s289.nodes.127_0_0_130:9043.retries.aborted',
tags=[]}=io.smallrye.metrics.app.CounterImpl@52d5fde2,
MetricID{name='s289.nodes.127_0_0_130:9043.retries.other',
tags=[]}=io.smallrye.metrics.app.CounterImpl@76fb45c2,
MetricID{name='s289.nodes.127_0_0_130:9043.retries.read-timeout',
tags=[]}=io.smallrye.metrics.app.CounterImpl@10584be0,
MetricID{name='s289.nodes.127_0_0_130:9043.retries.total',
tags=[]}=io.smallrye.metrics.app.CounterImpl@6df717af,
MetricID{name='s289.n
[jira] [Commented] (CASSANDRA-19603) Upgrade deprecated asyncore to asyncio
[ https://issues.apache.org/jira/browse/CASSANDRA-19603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842540#comment-17842540 ] Bret McGuire commented on CASSANDRA-19603: -- Note: PYTHON-1366 (the ticket for PR 1187) returns a DependencyException when we're unable to find a working event loop. [PYTHON-1375|https://datastax-oss.atlassian.net/browse/PYTHON-1375] aims to make sure the existing asyncio reactor is ready for prime time and is the new default reactor. The current plan is that PYTHON-1375 will be included in the next release (3.30.0), although due to other commitments work on that release has been delayed a bit. > Upgrade deprecated asyncore to asyncio > -- > > Key: CASSANDRA-19603 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19603 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > > The asyncore module is deprecated and has been removed in Python 3.12. To > support 3.12, we need to upgrade to use asyncio. > DEBUG test_cqlsh:run_cqlsh.py:194 read ' from cqlshlib.cqlshmain import > main\r\n File "pylib/cqlshlib/cqlshmain.py", line 37, in \r\n > from cassandra.cluster import Cluster\r\n File > "lib/cassandra-driver-internal-only-3.29.0.zip/cassandra-driver-3.29.0/cassandra/cluster.py", > line 173, in \r\ncassandra.DependencyException: Unable to load a > default connection class\r\nThe following exceptions were observed: \r\n - > The C extension needed to use libev was not found. This probably means that > you didn\'t have the required build dependencies when installing the driver. > See [http://datastax.github.io/python-driver/installation.html#c-extensions] > for instructions on installing build dependencies and building the C > extension.\r\n - Unable to import asyncore module. Note that this module has > been removed in Python 3.12 so when using the driver with this version (or > anything newer) you will need to use one of the other event loop > implementations.\r\n' from subproc -- 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-19598) advanced.resolve-contact-points: unresolved hostname being clobbered during reconnection
[
https://issues.apache.org/jira/browse/CASSANDRA-19598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842228#comment-17842228
]
Bret McGuire commented on CASSANDRA-19598:
--
No worries [~shot_up] , you're good... and thanks for bringing it to my
attention!
> advanced.resolve-contact-points: unresolved hostname being clobbered during
> reconnection
>
>
> Key: CASSANDRA-19598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19598
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andrew Orlowski
>Priority: Normal
> Attachments: image-2024-04-29-20-13-56-161.png,
> image-2024-04-29-20-40-53-382.png
>
>
> Hello, this is a bug ticket for 4.18.0 of the Java driver.
>
> I am running in an environment where I have 3 Cassandra nodes. We have a use
> case to redeploy the cluster from the ground up at midnight every day. This
> means that all 3 nodes become unavailable for a short period of time and 3
> new nodes with 3 new ip addresses get spun up and placed behind the contact
> point hostname. If you set {{advanced.resolve-contact-points}} to FALSE, the
> java driver should re-resolve the hostname for every new connection to that
> node. This occurs prior to and for the first redeployment, but the unresolved
> hostname is clobbered during the reconnection process and replaced with a
> resolved IP address, making additional redeployments fruitless. We provide a
> singular hostname as a contact point.
>
> In our case, what is happening is that all 3 nodes become unavailable while
> our CICD process is destroying the existing cluster and replacing it with a
> new one. During the window of unavailability, the Java driver attempts to
> reconnect to each node, two of which internally (internal to the driver) have
> resolved IP addresses and one of which retains the unresolved hostname. Here
> is a screenshot that captures the internal state of the 3 nodes within
> `PoolManager` prior to the finished redeployment of the cluster. Note that
> there are 2 resolved IP addresses and 1 unresolved hostname.
> !image-2024-04-29-20-13-56-161.png|width=985,height=181!
> This ratio of resolved IP:unresolved hostname is the correct internal state
> for a 3 node cluster when `advanced.resolve-contact-points` is set to `FALSE`.
> Eventually, the hostname points to one of the 3 new valid nodes, and the java
> driver reconnects and discovers the new peers. However, as part of this
> reconnection process, the internal Node that held the unresolved hostname is
> now overwritten with a Node that has the resolved IP address:
> !image-2024-04-29-20-40-53-382.png|width=1080,height=102!
> Note that we no longer have 2 resolved IP addresses and 1 unresolved
> hostname; rather, we have 3 resolved IP addresses, which is an incorrect
> internal state when `advanced.resolve-contact-points` is set to `FALSE`. One
> of the nodes should have retained the unresolved hostname.
> At this stage, the Java driver no longer queries the hostname for new
> connections, and further redeployments of ours result in failure because the
> hostname is no longer amongst the list of nodes that are queried for
> reconnection. This causes us to need to restart the application.
--
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-19579) threads lingering after driver shutdown: session close starts thread and doesn't await its stop
[
https://issues.apache.org/jira/browse/CASSANDRA-19579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842045#comment-17842045
]
Bret McGuire commented on CASSANDRA-19579:
--
ACKed [~brandon.williams] ; thanks for letting me know. The
"Client/java-driver" component will usually do the trick but an explicit "cc"
tag never hurts :)
> threads lingering after driver shutdown: session close starts thread and
> doesn't await its stop
> ---
>
> Key: CASSANDRA-19579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19579
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Thomas Klambauer
>Priority: Normal
>
> We are checking remaining/lingering threads during shutdown.
> we noticed some with naming pattern/thread factory:
> ""globalEventExecutor-1-2" Id=146 TIMED_WAITING"
> this one seems to be created during shutdown / session close and not
> awaited/shut down:
> {noformat}
> addTask:156, GlobalEventExecutor (io.netty.util.concurrent)
> execute0:225, GlobalEventExecutor (io.netty.util.concurrent)
> execute:221, GlobalEventExecutor (io.netty.util.concurrent)
> onClose:188, DefaultNettyOptions
> (com.datastax.oss.driver.internal.core.context)
> onChildrenClosed:589, DefaultSession$SingleThreaded
> (com.datastax.oss.driver.internal.core.session)
> lambda$close$9:552, DefaultSession$SingleThreaded
> (com.datastax.oss.driver.internal.core.session)
> run:-1, 860270832
> (com.datastax.oss.driver.internal.core.session.DefaultSession$SingleThreaded$$Lambda$9508)
> tryFire$$$capture:783, CompletableFuture$UniRun (java.util.concurrent)
> tryFire:-1, CompletableFuture$UniRun (java.util.concurrent)
> - Async stack trace
> addTask:-1, SingleThreadEventExecutor (io.netty.util.concurrent)
> execute:836, SingleThreadEventExecutor (io.netty.util.concurrent)
> execute0:827, SingleThreadEventExecutor (io.netty.util.concurrent)
> execute:817, SingleThreadEventExecutor (io.netty.util.concurrent)
> claim:568, CompletableFuture$UniCompletion (java.util.concurrent)
> tryFire$$$capture:780, CompletableFuture$UniRun (java.util.concurrent)
> tryFire:-1, CompletableFuture$UniRun (java.util.concurrent)
> - Async stack trace
> :767, CompletableFuture$UniRun (java.util.concurrent)
> uniRunStage:801, CompletableFuture (java.util.concurrent)
> thenRunAsync:2136, CompletableFuture (java.util.concurrent)
> thenRunAsync:143, CompletableFuture (java.util.concurrent)
> whenAllDone:75, CompletableFutures
> (com.datastax.oss.driver.internal.core.util.concurrent)
> close:551, DefaultSession$SingleThreaded
> (com.datastax.oss.driver.internal.core.session)
> access$1000:300, DefaultSession$SingleThreaded
> (com.datastax.oss.driver.internal.core.session)
> lambda$closeAsync$1:272, DefaultSession
> (com.datastax.oss.driver.internal.core.session)
> runTask:98, PromiseTask (io.netty.util.concurrent)
> run:106, PromiseTask (io.netty.util.concurrent)
> runTask$$$capture:174, AbstractEventExecutor (io.netty.util.concurrent)
> runTask:-1, AbstractEventExecutor (io.netty.util.concurrent)
> - Async stack trace
> addTask:-1, SingleThreadEventExecutor (io.netty.util.concurrent)
> execute:836, SingleThreadEventExecutor (io.netty.util.concurrent)
> execute0:827, SingleThreadEventExecutor (io.netty.util.concurrent)
> execute:817, SingleThreadEventExecutor (io.netty.util.concurrent)
> submit:118, AbstractExecutorService (java.util.concurrent)
> submit:118, AbstractEventExecutor (io.netty.util.concurrent)
> on:57, RunOrSchedule (com.datastax.oss.driver.internal.core.util.concurrent)
> closeSafely:286, DefaultSession
> (com.datastax.oss.driver.internal.core.session)
> closeAsync:272, DefaultSession (com.datastax.oss.driver.internal.core.session)
> close:76, AsyncAutoCloseable (com.datastax.oss.driver.api.core)
> -- custom shutdown code
> run:829, Thread (java.lang)
> {noformat}
> the initial close here is called on
> com.datastax.oss.driver.api.core.CqlSession.
> netty framework suggests to call
> io.netty.util.concurrent.GlobalEventExecutor#awaitInactivity
> during shutdown to await event thread stopping
> (slightly related issue in netty:
> [https://github.com/netty/netty/issues/2084] )
> suggestion to add maybe GlobalEventExecutor.INSTANCE.awaitInactivity with
> some timeout during close around here:
> [https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/internal/core/context/DefaultNettyOptions.java#L199]
> noting that this might slow down closing for up to 2 seconds if the netty
> issue comment is correct.
> this is on latest datastax java driver version: 4.17,
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To
[jira] [Updated] (CASSANDRA-19292) Update target Cassandra versions for integration tests, support new 4.0.x and 4.1.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19292: - Resolution: Fixed Status: Resolved (was: Open) > Update target Cassandra versions for integration tests, support new 4.0.x and > 4.1.x > --- > > Key: CASSANDRA-19292 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19292 > Project: Cassandra > Issue Type: Task > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver runs against 4.0.0 but not newer > 4.0.x or 4.1.x releases: > https://github.com/apache/cassandra-java-driver/blob/4.x/core/src/main/java/com/datastax/oss/driver/api/core/Version.java#L54C1-L55C1 > 4.1 introduces changes to config as well, so there are failures to start CCM > clusters if we do a naive version bump, like: > "org.apache.cassandra.exceptions.ConfigurationException: Config contains both > old and new keys for the same configuration parameters, migrate old -> new: > [enable_user_defined_functions -> user_defined_functions_enabled]" > I have a patch ready for this, working on preparing it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19568) Jennkins pipeline's default Java version for Jabba has changed
[ https://issues.apache.org/jira/browse/CASSANDRA-19568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839037#comment-17839037 ] Bret McGuire commented on CASSANDRA-19568: -- To be clear: this ticket covers a Jenkins update on DataStax infrastructure and not anything related to the ASF CI > Jennkins pipeline's default Java version for Jabba has changed > -- > > Key: CASSANDRA-19568 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19568 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Jane He >Assignee: Henry Hughes >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > We need Java 8 to build the driver. In the past, `jabba use default` will use > Java 8. After a jenkins runner update, it uses java 11 now. Therefore, we > have to specify `jabba use 1.8` instead before we build the driver. -- 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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19457:
-
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro-1.java, Repro.java, Screenshot 2024-03-06 at
> 2.07.01 PM.png, Screenshot 2024-03-06 at 2.07.13 PM.png, build-1.gradle,
> build.gradle
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19468:
-
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Ammar Khaku
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17835064#comment-17835064
]
Bret McGuire commented on CASSANDRA-19457:
--
I just tested this (using the Repro case above) with the following
configurations:
MIcrometer, MicroProfile and default metrics X 4.18.0 and 4.18.1-SNAPSHOT
containing the fix from [~janesiyaohe]
I observed the leak in both the Micrometer and MicroProfile case using 4.18.0.
In all other cases the leak wasn't observed. This indicates that Jane's fix
appears to address Micrometer and MicroProfile and that the default case did
not have an issue.
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro-1.java, Repro.java, Screenshot 2024-03-06 at
> 2.07.01 PM.png, Screenshot 2024-03-06 at 2.07.13 PM.png, build-1.gradle,
> build.gradle
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834455#comment-17834455
]
Bret McGuire commented on CASSANDRA-19457:
--
I'm attaching a couple of files that will be useful to help repro this case.
[^build.gradle]
[^Repro.java]
The Java file continually opens and closes sessions against an Astra database.
If you monitor the number of DefaultSession instances with a profiler (visualvm
works great for this) you should see the count of instances increase
monotonically. When the patch for this ticket is applied you should see this
number decrease occasionally when GC is performed.
The attached Gradle file will build (and run) the repro case with all necessary
Micrometer and MicroProfile classes in the classpath. You can select either
Micrometer or MicroProfile metrics via a system prop when kicking things off;
if you don't select either option the default (Dropwizard) will be used.
"./gradlew build" should just work. "./gradlew run -Dmicrometer=1" or
"./gradlew run -Dmicroprofile=1" are examples of using alternate registries for
testing.
You'll also need an astra.props file containing Astra creds + SCB. It should
be easy enough to tweak this to use a local C* cluster if you prefer that.
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro-1.java, Repro.java, Screenshot 2024-03-06 at
> 2.07.01 PM.png, Screenshot 2024-03-06 at 2.07.13 PM.png, build-1.gradle,
> build.gradle
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19457:
-
Attachment: build-1.gradle
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro.java, Screenshot 2024-03-06 at 2.07.01 PM.png,
> Screenshot 2024-03-06 at 2.07.13 PM.png, build-1.gradle, build.gradle
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19457:
-
Attachment: Repro-1.java
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro-1.java, Repro.java, Screenshot 2024-03-06 at
> 2.07.01 PM.png, Screenshot 2024-03-06 at 2.07.13 PM.png, build-1.gradle,
> build.gradle
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19457:
-
Attachment: build.gradle
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro.java, Screenshot 2024-03-06 at 2.07.01 PM.png,
> Screenshot 2024-03-06 at 2.07.13 PM.png, build.gradle
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19457:
-
Attachment: Repro.java
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Repro.java, Screenshot 2024-03-06 at 2.07.01 PM.png,
> Screenshot 2024-03-06 at 2.07.13 PM.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19501) GraalLibc.gettimeofday() is misbehaving in new GraalVM versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17833256#comment-17833256 ] Bret McGuire commented on CASSANDRA-19501: -- Important note: this will be changing again in future versions of Graal. See [this issue|https://github.com/oracle/graal/issues/8683] for more details. > GraalLibc.gettimeofday() is misbehaving in new GraalVM versions > --- > > Key: CASSANDRA-19501 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19501 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Priority: Normal > > As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the > Java driver relies on System.nanoTime() for it's impl of > Native.gettimeofday() on GraalVM. Underlying rationale there was a > [substitution on older Substrate impls > |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] > which appeared to rely on gettimeofday() for it's replacement of > System.nanoTime(). This was an unfortunate misreading of the source; it > falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, > and on most modern systems that won't fail at all. In fact new versions of > GraalVM [don't even bother with the fallback|#L37-L53].]. That leaves us > returning values from the monotonic clock as answers to gettimeofday() ops > and those values... do not correlate to the time of day at all. > > Seems like the simplest answer is just to inline the gettimeofday() logic > into GraalLibc.gettimeofdayRaw(). -- 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-19506) Add Jenkins support for testing against Cassandra 4.1
Bret McGuire created CASSANDRA-19506: Summary: Add Jenkins support for testing against Cassandra 4.1 Key: CASSANDRA-19506 URL: https://issues.apache.org/jira/browse/CASSANDRA-19506 Project: Cassandra Issue Type: Bug Components: Client/java-driver Reporter: Bret McGuire Assignee: Henry Hughes Currently hung up on the ccm invocation due to the recent cassandra.yaml property migration -- 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-19504) Jenkinsfile doesn't invoke tests with the correct Java versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19504: - Resolution: Fixed Status: Resolved (was: Triage Needed) > Jenkinsfile doesn't invoke tests with the correct Java versions > --- > > Key: CASSANDRA-19504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19504 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: Normal > Time Spent: 1.5h > Remaining Estimate: 0h > > The existing Jenkinsfile is intended to run tests against multiple Java > versions (8, 11, 17). However, due to the concurrency in multiple matrix jobs > and the global scope of `TEST_JAVA_VERSION` and `TEST_JAVA_HOME`, the jobs > are actually only run against one version. > This can be fixed by defining these variables locally, using `def` keyword. -- 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-19504) Jenkinsfile doesn't invoke tests with the correct Java versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832042#comment-17832042 ] Bret McGuire edited comment on CASSANDRA-19504 at 3/29/24 5:31 AM: --- Current Jenkinsfile includes a 3x3 matrix (C* 3.11 and 4.0 + DSE 6.8 X Java 8, 11 and 17) for running unit and integration tests. We're seeing tests that should be run against Java8 using Java17, tests which should be using Java11 using Java8 and so on. Results vary wildly; there's no consistency as to which JVM is used for a given C*/Java pair. Belief is that the underlying cause here are changes that came in with [this PR|https://github.com/apache/cassandra-java-driver/pull/1663]. These changes introduced a few additional args to the "mvn verify" invocation; these args are passed through env vars computed by the Jenkinsfile itself. Best guess is that this mechanism for state management gets confused when invoking the 3x3 matrix which leads to random JVM selection for a given run. As mentioned by [~janesiyaohe] we should be able to address this via better state management. Note that this issue affects the DataStax Java driver CI implementation only; we don't have ASF CI setup for the Java driver yet. We have to fix it by modifying the Jenkinsfile, however, so a CASSANDRA ticket seemed appropriate. was (Author: JIRAUSER304104): Current Jenkinsfile includes a 3x3 matrix (C* 3.11 and 4.0 + DSE 6.8 X Java 8, 11 and 17) for running unit and integration tests. We're seeing tests that should be run against Java8 using Java17, tests which should be using Java11 using Java8 and so on. Results vary wildly; there's no consistency as to which JVM is used for a given C*/Java pair. Belief is that the underlying cause here are changes that came in with [this PR|https://github.com/apache/cassandra-java-driver/pull/1663]. These changes introduced a few additional args to the "mvn verify" invocation; these args are passed through env vars computed by the Jenkinsfile itself. Best guess is that this mechanism for state management gets confused when invoking the 3x3 matrix which leads to random JVM selection for a given run. As mentioned by [~janesiyaohe] we should be able to address this via better state management. > Jenkinsfile doesn't invoke tests with the correct Java versions > --- > > Key: CASSANDRA-19504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19504 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: Normal > > The existing Jenkinsfile is intended to run tests against multiple Java > versions (8, 11, 17). However, due to the concurrency in multiple matrix jobs > and the global scope of `TEST_JAVA_VERSION` and `TEST_JAVA_HOME`, the jobs > are actually only run against one version. > This can be fixed by defining these variables locally, using `def` keyword. -- 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-19504) Jenkinsfile doesn't invoke tests with the correct Java versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832042#comment-17832042 ] Bret McGuire commented on CASSANDRA-19504: -- Current Jenkinsfile includes a 3x3 matrix (C* 3.11 and 4.0 + DSE 6.8 X Java 8, 11 and 17) for running unit and integration tests. We're seeing tests that should be run against Java8 using Java17, tests which should be using Java11 using Java8 and so on. Results vary wildly; there's no consistency as to which JVM is used for a given C*/Java pair. Belief is that the underlying cause here are changes that came in with [this PR|https://github.com/apache/cassandra-java-driver/pull/1663]. These changes introduced a few additional args to the "mvn verify" invocation; these args are passed through env vars computed by the Jenkinsfile itself. Best guess is that this mechanism for state management gets confused when invoking the 3x3 matrix which leads to random JVM selection for a given run. As mentioned by [~janesiyaohe] we should be able to address this via better state management. > Jenkinsfile doesn't invoke tests with the correct Java versions > --- > > Key: CASSANDRA-19504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19504 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: Normal > > The existing Jenkinsfile is intended to run tests against multiple Java > versions (8, 11, 17). However, due to the concurrency in multiple matrix jobs > and the global scope of `TEST_JAVA_VERSION` and `TEST_JAVA_HOME`, the jobs > are actually only run against one version. > This can be fixed by defining these variables locally, using `def` keyword. -- 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-19504) Jenkinsfile doesn't invoke tests with the correct Java versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19504: - Summary: Jenkinsfile doesn't invoke tests with the correct Java versions (was: Jenkins Jobs Run Tests against Only 1 Java Version Instead of 3) > Jenkinsfile doesn't invoke tests with the correct Java versions > --- > > Key: CASSANDRA-19504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19504 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Jane He >Assignee: Jane He >Priority: Normal > > The existing Jenkinsfile is intended to run tests against multiple Java > versions (8, 11, 17). However, due to the concurrency in multiple matrix jobs > and the global scope of `TEST_JAVA_VERSION` and `TEST_JAVA_HOME`, the jobs > are actually only run against one version. > This can be fixed by defining these variables locally, using `def` keyword. -- 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-19501) GraalLibc.gettimeofday() is misbehaving in new GraalVM versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831592#comment-17831592 ] Bret McGuire commented on CASSANDRA-19501: -- Hat tip to [~alberto.bortolan] for bringing this to my attention! > GraalLibc.gettimeofday() is misbehaving in new GraalVM versions > --- > > Key: CASSANDRA-19501 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19501 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Priority: Normal > > As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the > Java driver relies on System.nanoTime() for it's impl of > Native.gettimeofday() on GraalVM. Underlying rationale there was a > [substitution on older Substrate impls > |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] > which appeared to rely on gettimeofday() for it's replacement of > System.nanoTime(). This was an unfortunate misreading of the source; it > falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, > and on most modern systems that won't fail at all. In fact new versions of > GraalVM [don't even bother with the fallback|#L37-L53].]. That leaves us > returning values from the monotonic clock as answers to gettimeofday() ops > and those values... do not correlate to the time of day at all. > > Seems like the simplest answer is just to inline the gettimeofday() logic > into GraalLibc.gettimeofdayRaw(). -- 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-19501) GraalLibc.gettimeofday() is misbehaving in new GraalVM versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19501: - Description: As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the Java driver relies on System.nanoTime() for it's impl of Native.gettimeofday() on GraalVM. Underlying rationale there was a [substitution on older Substrate impls |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] which appeared to rely on gettimeofday() for it's replacement of System.nanoTime(). This was an unfortunate misreading of the source; it falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, and on most modern systems that won't fail at all. In fact new versions of GraalVM [don't even bother with the fallback|#L37-L53].]. That leaves us returning values from the monotonic clock as answers to gettimeofday() ops and those values... do not correlate to the time of day at all. Seems like the simplest answer is just to inline the gettimeofday() logic into GraalLibc.gettimeofdayRaw(). was: As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the Java driver relies on System.nanoTime() for it's impl of Native.gettimeofday() on GraalVM. Underlying rationale there was a [substitution on older Substrate impls |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] which appeared to rely on gettimeofday() for it's replacement of System.nanoTime(). This was an unfortunate misreading of the source; it falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, and on most modern systems that won't fail at all. In fact new versions of GraalVM [don't even bother with the fallback|[https://github.com/oracle/graal/blob/jdk-17.0.10/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L37-L53].] Seems like the simplest answer is just to inline the gettimeofday() logic into GraalLibc.gettimeofdayRaw(). > GraalLibc.gettimeofday() is misbehaving in new GraalVM versions > --- > > Key: CASSANDRA-19501 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19501 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Priority: Normal > > As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the > Java driver relies on System.nanoTime() for it's impl of > Native.gettimeofday() on GraalVM. Underlying rationale there was a > [substitution on older Substrate impls > |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] > which appeared to rely on gettimeofday() for it's replacement of > System.nanoTime(). This was an unfortunate misreading of the source; it > falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, > and on most modern systems that won't fail at all. In fact new versions of > GraalVM [don't even bother with the fallback|#L37-L53].]. That leaves us > returning values from the monotonic clock as answers to gettimeofday() ops > and those values... do not correlate to the time of day at all. > > Seems like the simplest answer is just to inline the gettimeofday() logic > into GraalLibc.gettimeofdayRaw(). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19501) GraalLibc.gettimeofday() is misbehaving in new GraalVM versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire reassigned CASSANDRA-19501: Assignee: (was: Henry Hughes) > GraalLibc.gettimeofday() is misbehaving in new GraalVM versions > --- > > Key: CASSANDRA-19501 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19501 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Bret McGuire >Priority: Normal > > As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the > Java driver relies on System.nanoTime() for it's impl of > Native.gettimeofday() on GraalVM. Underlying rationale there was a > [substitution on older Substrate impls > |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] > which appeared to rely on gettimeofday() for it's replacement of > System.nanoTime(). This was an unfortunate misreading of the source; it > falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, > and on most modern systems that won't fail at all. In fact new versions of > GraalVM [don't even bother with the > fallback|[https://github.com/oracle/graal/blob/jdk-17.0.10/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L37-L53].] > > Seems like the simplest answer is just to inline the gettimeofday() logic > into GraalLibc.gettimeofdayRaw(). -- 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-19501) GraalLibc.gettimeofday() is misbehaving in new GraalVM versions
Bret McGuire created CASSANDRA-19501: Summary: GraalLibc.gettimeofday() is misbehaving in new GraalVM versions Key: CASSANDRA-19501 URL: https://issues.apache.org/jira/browse/CASSANDRA-19501 Project: Cassandra Issue Type: Bug Components: Client/java-driver Reporter: Bret McGuire Assignee: Henry Hughes As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the Java driver relies on System.nanoTime() for it's impl of Native.gettimeofday() on GraalVM. Underlying rationale there was a [substitution on older Substrate impls |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58] which appeared to rely on gettimeofday() for it's replacement of System.nanoTime(). This was an unfortunate misreading of the source; it falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, and on most modern systems that won't fail at all. In fact new versions of GraalVM [don't even bother with the fallback|[https://github.com/oracle/graal/blob/jdk-17.0.10/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L37-L53].] Seems like the simplest answer is just to inline the gettimeofday() logic into GraalLibc.gettimeofdayRaw(). -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19180: - Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-java-driver/commit/8e73232102d6275b4f13de9d089d3a9b224c9727 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Fix For: NA > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831396#comment-17831396 ] Bret McGuire commented on CASSANDRA-19333: -- Makes sense to me [~e.dimitrova]! I've done the same to CASSANDRA-19180 > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: NA > > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831081#comment-17831081 ] Bret McGuire commented on CASSANDRA-19333: -- [~e.dimitrova] I'm perfectly fine with that. [~aratnofsky] was asking a very similar question about CASSANDRA-19180 so whatever we do here we should probably do for that ticket as well. > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19180: - Reviewers: Andy Tolbert, Bret McGuire (was: absurdfarce#1, Andy Tolbert) Status: Review In Progress (was: Needs Committer) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19180: - Status: Ready to Commit (was: Review In Progress) > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829966#comment-17829966 ] Bret McGuire commented on CASSANDRA-19333: -- Committed as [40a9a49d50fac6abed2a5bb2cc2627e4085a399b|https://github.com/apache/cassandra-java-driver/commit/40a9a49d50fac6abed2a5bb2cc2627e4085a399b]. Huge thank you to [~e.dimitrova] for making this happen! > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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-19352) 4.x Java driver support for native_port_ssl and native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-19352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19352: - Resolution: Fixed Status: Resolved (was: Triage Needed) > 4.x Java driver support for native_port_ssl and native_transport_port_ssl > - > > Key: CASSANDRA-19352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19352 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: absurdfarce#1 >Assignee: Bret McGuire >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > DSE 6.8 added a "native_transport_port_ssl" column to peers_v2 to indicate > when peers were making use of "native_transport_port_ssl" in cassandra.yaml. > Similar functionality (with slightly different column names) was brought to > OSS Cassandra with CASSANDRA-16999. 3.x Java driver support for these > columns has been added (or is in the process of being added) in > [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. This ticket > represents the work to implement similar functionality for the 4.x Java > driver. -- 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-19352) 4.x Java driver support for native_port_ssl and native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-19352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire updated CASSANDRA-19352: - Component/s: Client/java-driver > 4.x Java driver support for native_port_ssl and native_transport_port_ssl > - > > Key: CASSANDRA-19352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19352 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: absurdfarce#1 >Priority: Normal > > DSE 6.8 added a "native_transport_port_ssl" column to peers_v2 to indicate > when peers were making use of "native_transport_port_ssl" in cassandra.yaml. > Similar functionality (with slightly different column names) was brought to > OSS Cassandra with CASSANDRA-16999. 3.x Java driver support for these > columns has been added (or is in the process of being added) in > [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. This ticket > represents the work to implement similar functionality for the 4.x Java > driver. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19352) 4.x Java driver support for native_port_ssl and native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-19352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bret McGuire reassigned CASSANDRA-19352: Assignee: Bret McGuire > 4.x Java driver support for native_port_ssl and native_transport_port_ssl > - > > Key: CASSANDRA-19352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19352 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: absurdfarce#1 >Assignee: Bret McGuire >Priority: Normal > > DSE 6.8 added a "native_transport_port_ssl" column to peers_v2 to indicate > when peers were making use of "native_transport_port_ssl" in cassandra.yaml. > Similar functionality (with slightly different column names) was brought to > OSS Cassandra with CASSANDRA-16999. 3.x Java driver support for these > columns has been added (or is in the process of being added) in > [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. This ticket > represents the work to implement similar functionality for the 4.x Java > driver. -- 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-19352) 4.x Java driver support for native_port_ssl and native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-19352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829592#comment-17829592 ] Bret McGuire commented on CASSANDRA-19352: -- Per the discussion in CASSANDRA-16999 we won't be adding support for "native_transport_port_ssl" to OSS Cassandra. The Java driver does still need to add this support in order to work properly with DSE 6.8+, however, so this ticket will address that change. > 4.x Java driver support for native_port_ssl and native_transport_port_ssl > - > > Key: CASSANDRA-19352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19352 > Project: Cassandra > Issue Type: Improvement >Reporter: absurdfarce#1 >Priority: Normal > > DSE 6.8 added a "native_transport_port_ssl" column to peers_v2 to indicate > when peers were making use of "native_transport_port_ssl" in cassandra.yaml. > Similar functionality (with slightly different column names) was brought to > OSS Cassandra with CASSANDRA-16999. 3.x Java driver support for these > columns has been added (or is in the process of being added) in > [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. This ticket > represents the work to implement similar functionality for the 4.x Java > driver. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire reassigned CASSANDRA-19468:
Assignee: (was: Henry Hughes)
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Priority: Normal
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19468:
-
Authors: (was: Henry Hughes)
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Henry Hughes
>Priority: Normal
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17826896#comment-17826896
]
Bret McGuire commented on CASSANDRA-19468:
--
If we could get to a test case that would repro this as well that would be
fantastic!
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Henry Hughes
>Priority: Normal
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
[
https://issues.apache.org/jira/browse/CASSANDRA-19468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17826894#comment-17826894
]
Bret McGuire commented on CASSANDRA-19468:
--
Huge hat tip to Github user "vararo27" for pointing out the issue and
[persisting in
dialog|https://github.com/apache/cassandra-java-driver/pull/1918] to make sure
we identify it correctly!
> In some situations MetadataManager.SingleThreaded.startSchemaRequest could
> fail to set CompletableFuture arg
>
>
> Key: CASSANDRA-19468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Bret McGuire
>Assignee: Henry Hughes
>Priority: Normal
>
> Relevant code is:
>
>
> {code:java}
> private void startSchemaRequest(CompletableFuture
> refreshFuture) {
> assert adminExecutor.inEventLoop();
> if (closeWasCalled) {
> refreshFuture.complete(new RefreshSchemaResult(metadata));
> return;
> }
> if (currentSchemaRefresh == null) {
> currentSchemaRefresh = refreshFuture;
> LOG.debug("[{}] Starting schema refresh", logPrefix);
> initControlConnectionForSchema()
> .thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
> .whenComplete(
> (schemaInAgreement, agreementError) -> {
> if (agreementError != null) {
> refreshFuture.completeExceptionally(agreementError);
> } else {
> schemaQueriesFactory
> .newInstance()
> .execute()
> .thenApplyAsync(this::parseAndApplySchemaRows,
> adminExecutor)
> .whenComplete(
> (newMetadata, metadataError) -> {
> if (metadataError != null) {
>
> refreshFuture.completeExceptionally(metadataError);
> } else {
> refreshFuture.complete(
> new RefreshSchemaResult(newMetadata,
> schemaInAgreement));
> }
> ...{code}
>
>
> Problem is that the default impl of SchemaQueriesFactory
> (DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most
> notably if the control connection is in a bad way:
>
>
> {code:java}
> @Override
> public SchemaQueries newInstance() {
> DriverChannel channel = context.getControlConnection().channel();
> if (channel == null || channel.closeFuture().isDone()) {
> throw new IllegalStateException("Control channel not available, aborting
> schema refresh");
> }
> Node node =
> context
> .getMetadataManager()
> .getMetadata()
> .findNode(channel.getEndPoint())
> .orElseThrow(
> () ->
> new IllegalStateException(
> "Could not find control node metadata "
> + channel.getEndPoint()
> + ", aborting schema refresh"));
> return newInstance(node, channel);
> } {code}
>
>
>
> In this case the MetadataManager code above will exit out before it ever sets
> a state on refreshFuture... meaning anything waiting on that future will just
> continue to wait.
>
>
--
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-19468) In some situations MetadataManager.SingleThreaded.startSchemaRequest could fail to set CompletableFuture arg
Bret McGuire created CASSANDRA-19468:
Summary: In some situations
MetadataManager.SingleThreaded.startSchemaRequest could fail to set
CompletableFuture arg
Key: CASSANDRA-19468
URL: https://issues.apache.org/jira/browse/CASSANDRA-19468
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Bret McGuire
Assignee: Henry Hughes
Relevant code is:
{code:java}
private void startSchemaRequest(CompletableFuture
refreshFuture) {
assert adminExecutor.inEventLoop();
if (closeWasCalled) {
refreshFuture.complete(new RefreshSchemaResult(metadata));
return;
}
if (currentSchemaRefresh == null) {
currentSchemaRefresh = refreshFuture;
LOG.debug("[{}] Starting schema refresh", logPrefix);
initControlConnectionForSchema()
.thenCompose(v -> context.getTopologyMonitor().checkSchemaAgreement())
.whenComplete(
(schemaInAgreement, agreementError) -> {
if (agreementError != null) {
refreshFuture.completeExceptionally(agreementError);
} else {
schemaQueriesFactory
.newInstance()
.execute()
.thenApplyAsync(this::parseAndApplySchemaRows,
adminExecutor)
.whenComplete(
(newMetadata, metadataError) -> {
if (metadataError != null) {
refreshFuture.completeExceptionally(metadataError);
} else {
refreshFuture.complete(
new RefreshSchemaResult(newMetadata,
schemaInAgreement));
}
...{code}
Problem is that the default impl of SchemaQueriesFactory
(DefaultSchemaQueriesFactory) can chuck exceptions in a few cases, most notably
if the control connection is in a bad way:
{code:java}
@Override
public SchemaQueries newInstance() {
DriverChannel channel = context.getControlConnection().channel();
if (channel == null || channel.closeFuture().isDone()) {
throw new IllegalStateException("Control channel not available, aborting
schema refresh");
}
Node node =
context
.getMetadataManager()
.getMetadata()
.findNode(channel.getEndPoint())
.orElseThrow(
() ->
new IllegalStateException(
"Could not find control node metadata "
+ channel.getEndPoint()
+ ", aborting schema refresh"));
return newInstance(node, channel);
} {code}
In this case the MetadataManager code above will exit out before it ever sets a
state on refreshFuture... meaning anything waiting on that future will just
continue to wait.
--
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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817502#comment-17817502 ] Bret McGuire edited comment on CASSANDRA-19180 at 3/11/24 10:52 PM: Thanks [~brandon.williams]. With your +1 we have two approvals from committers so we're all set). was (Author: JIRAUSER304104): Thanks [~brandon.williams] ! With your +1 we have two approvals from committers so we're all set! > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19457) Object reference in Micrometer metrics prevent GC from reclaiming Session instances
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19457:
-
Summary: Object reference in Micrometer metrics prevent GC from reclaiming
Session instances (was: Memory Leak of `DefaultSession`)
> Object reference in Micrometer metrics prevent GC from reclaiming Session
> instances
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Screenshot 2024-03-06 at 2.07.01 PM.png, Screenshot
> 2024-03-06 at 2.07.13 PM.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Memory Leak of `DefaultSession`
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824523#comment-17824523
]
Bret McGuire edited comment on CASSANDRA-19457 at 3/7/24 8:19 PM:
--
I burned through several different hypotheses about what might actually be
going on here:
* Similar issue to JAVA-3051 (i.e. node reference in LBP was keeping nodes
around and thus keeping metric writers around)
* Straight weak reference to the node in MicrometerNodeMetricUpdater
* Avoiding registering with the event bus in MicrometerMetricsFactory
None of these approaches had any impact.
So I thought perhaps I could try a more systematic approach... but I'm not sure
if the results there make me feel better or worse:
Can I recreate with:
* Just node stats?
** Yes, can still repro in this case
* Just session stats?
** Yes, can still repro in this case
* MicroProfile metrics?
** Yes, can still repro in this case
was (Author: JIRAUSER304104):
I burned through several different hypotheses about what might actually be
going on here:
* Similar issue to JAVA-3051 (i.e. node reference in LBP was keeping nodes
around and thus keeping metric writers around)
* Straight weak reference to the node in MicrometerNodeMetricUpdater
* Avoiding registering with the event bus in MicrometerMetricsFactory
None of these approaches had any impact.
So I thought perhaps I could try a more systematic approach... but I'm not sure
if the results there make me feel better or worse:
Can I recreate with:
* Just node stats?
* Yes, can still repro in this case
* Just session stats?
* Yes, can still repro in this case
* MicroProfile metrics?
* Yes, can still repro in this casef
> Memory Leak of `DefaultSession`
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Screenshot 2024-03-06 at 2.07.01 PM.png, Screenshot
> 2024-03-06 at 2.07.13 PM.png
>
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19457) Memory Leak of `DefaultSession`
[
https://issues.apache.org/jira/browse/CASSANDRA-19457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824523#comment-17824523
]
Bret McGuire commented on CASSANDRA-19457:
--
I burned through several different hypotheses about what might actually be
going on here:
* Similar issue to JAVA-3051 (i.e. node reference in LBP was keeping nodes
around and thus keeping metric writers around)
* Straight weak reference to the node in MicrometerNodeMetricUpdater
* Avoiding registering with the event bus in MicrometerMetricsFactory
None of these approaches had any impact.
So I thought perhaps I could try a more systematic approach... but I'm not sure
if the results there make me feel better or worse:
Can I recreate with:
* Just node stats?
* Yes, can still repro in this case
* Just session stats?
* Yes, can still repro in this case
* MicroProfile metrics?
* Yes, can still repro in this casef
> Memory Leak of `DefaultSession`
> ---
>
> Key: CASSANDRA-19457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19457
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Jane He
>Assignee: Jane He
>Priority: Normal
> Attachments: Screenshot 2024-03-06 at 2.07.01 PM.png, Screenshot
> 2024-03-06 at 2.07.13 PM.png
>
>
> There is a memory leak of previous closed {{{}DefaultSession{}}}s. It can be
> reproduced by this:
> {code:java}
> public static void main(String[] args) throws InterruptedException {
> Semaphore sema = new Semaphore(20);
> for (int i = 0; i < 1; i++) {
> new Thread(() -> {
> try {
> sema.acquire();
> try(CqlSession session = CqlSession.builder()
>
> .withCloudSecureConnectBundle(Paths.get("bundle.zip"))
> .withAuthCredentials("token", "")
> .build()) {
> // Do stuff
> }
> } catch (Exception e) {
> System.out.println(e);
> } finally {
> sema.release();
> }
> }).start();
> }
> }{code}
> On initial investigation, it seems like
> {{MicrometerMetricUpdater.initializeGauge()}} uses
> {{{}Gauge.{}}}{{{}_builder()_{}}} _using_ {{_Supplier_}} _._ This creates a
> strong reference that is causing the issue.
--
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-19180) Support reloading certificate stores in cassandra-java-driver
[ https://issues.apache.org/jira/browse/CASSANDRA-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817502#comment-17817502 ] Bret McGuire commented on CASSANDRA-19180: -- Thanks [~brandon.williams] ! With your +1 we have two approvals from committers so we're all set! > Support reloading certificate stores in cassandra-java-driver > - > > Key: CASSANDRA-19180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19180 > Project: Cassandra > Issue Type: New Feature > Components: Client/java-driver >Reporter: Abe Ratnofsky >Assignee: Abe Ratnofsky >Priority: Normal > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently, apache/cassandra-java-driver does not reload SSLContext when the > underlying certificate store files change. When the DefaultSslEngineFactory > (and the other factories) are set up, they build a fixed instance of > javax.net.ssl.SSLContext that doesn't change: > https://github.com/apache/cassandra-java-driver/blob/12e3e3ea027c51c5807e5e46ba542f894edfa4e7/core/src/main/java/com/datastax/oss/driver/internal/core/ssl/DefaultSslEngineFactory.java#L74 > This fixed SSLContext is used to negotiate SSL with the cluster, and if a > keystore is reloaded on disk it isn't picked up by the driver, and future > reconnections will fail if the keystore certificates have expired by the time > they're used to handshake a new connection. > We should reload client certificates so that applications that provide them > can use short-lived certificates and not require a bounce to pick up new > certificates. This is especially relevant in a world with CASSANDRA-18554 and > broad use of mTLS. > I have a patch for this that is nearly ready. Now that the project has moved > under apache/ - who can I work with to understand how CI works now? -- 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-19370) Intermittent test failures in SchemaIT
[
https://issues.apache.org/jira/browse/CASSANDRA-19370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814519#comment-17814519
]
Bret McGuire commented on CASSANDRA-19370:
--
Also worth noting that there are several older tickets in the DataStax Jira
which address similar issues:
https://datastax-oss.atlassian.net/browse/JAVA-2579
[https://datastax-oss.atlassian.net/browse/JAVA-1690]
So this one has been around for a while.
> Intermittent test failures in SchemaIT
> --
>
> Key: CASSANDRA-19370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19370
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bret McGuire
>Priority: Normal
>
> Noted on a few DataStax Jenkins runs of the Java driver test suite,
> specifically a test run for a recent PR for CASSANDRA-19290. Seems to be
> very intermittent.
>
> {code:java}
> Per-Commit / Matrix - SERVER_VERSION = 'dse-6.8.30', JABBA_VERSION =
> 'openjdk@1.11' / Execute-Tests /
> com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config{code}
>
> {noformat}
> Error MessageExpecting:
>
> {foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
> not to contain key:
> fooStacktracejava.lang.AssertionError:
> Expecting:
>
> {foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
> not to contain key:
> foo
> at
> com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config(SchemaIT.java:158)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:47)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:316)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19371) Intermittent test failures in ChannelPoolResizeTest
Bret McGuire created CASSANDRA-19371:
Summary: Intermittent test failures in ChannelPoolResizeTest
Key: CASSANDRA-19371
URL: https://issues.apache.org/jira/browse/CASSANDRA-19371
Project: Cassandra
Issue Type: Bug
Reporter: Bret McGuire
Noted on a recent DataStax Jenkins run against a PR for CASSANDRA-19290.
Failure seems to be intermittent.
{noformat}
Per-Commit / Matrix - SERVER_VERSION = 'dse-6.8.30', JABBA_VERSION =
'openjdk@1.11' / Execute-Tests /
com.datastax.oss.driver.internal.core.pool.ChannelPoolResizeTest.should_resize_during_reconnection_if_config_changes{noformat}
{noformat}
Error MessageExpecting:
[1]
to contain exactly (and in same order):
[0]
but some elements were not found:
[0]
and others were not expected:
[1]
Stacktracejava.lang.AssertionError:
Expecting:
[1]
to contain exactly (and in same order):
[0]
but some elements were not found:
[0]
and others were not expected:
[1]
at
com.datastax.oss.driver.internal.core.channel.MockChannelFactoryHelper.verifyNoMoreCalls(MockChannelFactoryHelper.java:114)
at
com.datastax.oss.driver.internal.core.pool.ChannelPoolResizeTest.should_resize_during_reconnection_if_config_changes(ChannelPoolResizeTest.java:379)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:49)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:120)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:95)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:69)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:146)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at
org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To un
[jira] [Updated] (CASSANDRA-19370) Intermittent test failures in SchemaIT
[
https://issues.apache.org/jira/browse/CASSANDRA-19370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19370:
-
Description:
Noted on a few DataStax Jenkins runs of the Java driver test suite,
specifically a test run for a recent PR for CASSANDRA-19290. Seems to be very
intermittent.
{code:java}
Per-Commit / Matrix - SERVER_VERSION = 'dse-6.8.30', JABBA_VERSION =
'openjdk@1.11' / Execute-Tests /
com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config{code}
{noformat}
Error MessageExpecting:
{foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
not to contain key:
fooStacktracejava.lang.AssertionError:
Expecting:
{foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
not to contain key:
foo
at
com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config(SchemaIT.java:158)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at
org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
at
org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:47)
at
org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:316)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at
org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833){noformat}
was:
Noted on a few DataStax Jenkins runs of the Java driver test suite. Seems to
be very intermittent.
{code:java}
Per-Commit / Matrix - SERVER_VERSION = 'dse-6.8.30', JABBA_VERSION =
'openjdk@1.11' / Execute-Tests /
com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config{code}
{noformat}
Error MessageExpecting:
{foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
not to contain key:
fooStacktracejava.lang.AssertionError:
Expecting:
{foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
not to contain key:
foo
at
com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config(SchemaIT.java:158)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.b
[jira] [Created] (CASSANDRA-19370) Intermittent test failures in SchemaIT
Bret McGuire created CASSANDRA-19370:
Summary: Intermittent test failures in SchemaIT
Key: CASSANDRA-19370
URL: https://issues.apache.org/jira/browse/CASSANDRA-19370
Project: Cassandra
Issue Type: Bug
Reporter: Bret McGuire
Noted on a few DataStax Jenkins runs of the Java driver test suite. Seems to
be very intermittent.
{code:java}
Per-Commit / Matrix - SERVER_VERSION = 'dse-6.8.30', JABBA_VERSION =
'openjdk@1.11' / Execute-Tests /
com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config{code}
{noformat}
Error MessageExpecting:
{foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
not to contain key:
fooStacktracejava.lang.AssertionError:
Expecting:
{foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
not to contain key:
foo
at
com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config(SchemaIT.java:158)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at
org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
at
org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:47)
at
org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:316)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at
org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19370) Intermittent test failures in SchemaIT
[
https://issues.apache.org/jira/browse/CASSANDRA-19370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814516#comment-17814516
]
Bret McGuire commented on CASSANDRA-19370:
--
Not immediately clear if there's anything DSE-specific about this failure or
not. The two cases I could find do involve runs against DSE but it's quite
possible the issue in this test is more general.
> Intermittent test failures in SchemaIT
> --
>
> Key: CASSANDRA-19370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19370
> Project: Cassandra
> Issue Type: Bug
>Reporter: Bret McGuire
>Priority: Normal
>
> Noted on a few DataStax Jenkins runs of the Java driver test suite. Seems to
> be very intermittent.
>
> {code:java}
> Per-Commit / Matrix - SERVER_VERSION = 'dse-6.8.30', JABBA_VERSION =
> 'openjdk@1.11' / Execute-Tests /
> com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config{code}
>
> {noformat}
> Error MessageExpecting:
>
> {foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
> not to contain key:
> fooStacktracejava.lang.AssertionError:
> Expecting:
>
> {foo=com.datastax.dse.driver.internal.core.metadata.schema.DefaultDseTableMetadata@a8599027}
> not to contain key:
> foo
> at
> com.datastax.oss.driver.core.metadata.SchemaIT.should_disable_schema_programmatically_when_enabled_in_config(SchemaIT.java:158)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
> at
> org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:47)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:316)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at
> org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:345)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19333) Fix decode in VectorCodec
[ https://issues.apache.org/jira/browse/CASSANDRA-19333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813428#comment-17813428 ] Bret McGuire commented on CASSANDRA-19333: -- Thanks for the PR [~e.dimitrova] ! That CONTRIBUTING.md doc is what I was going to point you at; it probably needs an update to account for a few changes after the donation to the ASF but most of the technical stuff should largely be correct. Unfortunately the state of CI is still in flux; work is ongoing to get ASF CI support up and running and we're working on updating the DataStax Jenkins instance to run tests for forked PRs. Neither of those are in a completed state at the moment. So running the tests locally is prolly the right answer for the very short-term. Specifically for this change VectorCodecTest will really be the clincher. That test includes a test case which tries to decode a vector with multiple elements. If that test succeeds we can be reasonably confident that the ByteBuffer processing changes are solid. They also _look_ sane as well, which is always nice. I'll try to finish up a review of this tonight but on a quick glance it doesn't look like there's anything terribly controversial here. > Fix decode in VectorCodec > - > > Key: CASSANDRA-19333 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19333 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > We made a server-side fix in CASSANDRA-19167 for VectorCodec. > This needs to be checked also in the driver [here > |https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/type/codec/VectorCodec.java#L130-L139] -- 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-19352) 4.x Java driver support for native_port_ssl and native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-19352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813053#comment-17813053 ] Bret McGuire commented on CASSANDRA-19352: -- Note: [~stefan.miklosovic] put together a [PR|https://github.com/apache/cassandra/pull/3076] aimed at addressing at least some part of this functionality. > 4.x Java driver support for native_port_ssl and native_transport_port_ssl > - > > Key: CASSANDRA-19352 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19352 > Project: Cassandra > Issue Type: Improvement >Reporter: Bret McGuire >Priority: Normal > > DSE 6.8 added a "native_transport_port_ssl" column to peers_v2 to indicate > when peers were making use of "native_transport_port_ssl" in cassandra.yaml. > Similar functionality (with slightly different column names) was brought to > OSS Cassandra with CASSANDRA-16999. 3.x Java driver support for these > columns has been added (or is in the process of being added) in > [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. This ticket > represents the work to implement similar functionality for the 4.x Java > driver. -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813052#comment-17813052 ] Bret McGuire commented on CASSANDRA-16999: -- Okay, so here's where things stand as of this writing. I've re-opened JAVA-2967 (where the original work was done to support this functionality for DSE 6.8 for the 3.x Java driver). That ticket will be used to govern the inclusion of similar functionality for OSS C* (since it already comes loaded with all the context). I've added a [PR|https://github.com/apache/cassandra-java-driver/pull/1911] for the 3.x Java driver which should add support for the OSS C* columns. I've also filed a new ticket (CASSANDRA-19352) aimed at bringing this functionality to the 4.x Java driver. > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-19352) 4.x Java driver support for native_port_ssl and native_transport_port_ssl
Bret McGuire created CASSANDRA-19352: Summary: 4.x Java driver support for native_port_ssl and native_transport_port_ssl Key: CASSANDRA-19352 URL: https://issues.apache.org/jira/browse/CASSANDRA-19352 Project: Cassandra Issue Type: Improvement Reporter: Bret McGuire DSE 6.8 added a "native_transport_port_ssl" column to peers_v2 to indicate when peers were making use of "native_transport_port_ssl" in cassandra.yaml. Similar functionality (with slightly different column names) was brought to OSS Cassandra with CASSANDRA-16999. 3.x Java driver support for these columns has been added (or is in the process of being added) in [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. This ticket represents the work to implement similar functionality for the 4.x Java driver. -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812793#comment-17812793 ] Bret McGuire commented on CASSANDRA-16999: -- I can confirm that your branch fixes the issue with native_transport_port_ssl [~smiklosovic] . I can also confirm that my test app still fails when run against a cluster with that version. It seems increasingly clear to me that my fix for JAVA-2967 is wrong. I'm working on fixing 3.x now. We'll also almost certainly need a driver fix for 4.x as well as discussed [here|https://datastax-oss.atlassian.net/browse/JAVA-2967?focusedCommentId=55384]. > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[
https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812561#comment-17812561
]
Bret McGuire commented on CASSANDRA-16999:
--
Hey [~smiklosovic] and [~brandon.williams] finally got some time to test
this this evening. Looks like we're not quite there yet. My testing process
went as follows:
* Create a three-node ccm cluster backed by Brandon's branch
* Add native_protocol_port_ssl to cassandra.yaml + configure
client_encryption_options
* Run a simple client app which attempts to connect to one of the nodes on
native_transport_port_ssl
* Look for exceptions like the following:
{noformat}
750 [s0-admin-0] DEBUG com.datastax.oss.driver.internal.core.pool.ChannelPool
- [s0|localhost/127.0.0.1:9142] Trying to create 1 missing channels
759 [s0-io-4] DEBUG
com.datastax.oss.driver.internal.core.channel.ProtocolInitHandler -
[s0|connecting...] Starting channel initialization
817 [s0-io-5] DEBUG
com.datastax.oss.driver.internal.core.channel.ProtocolInitHandler -
[s0|connecting...] Starting channel initialization
818 [s0-admin-0] WARN com.datastax.oss.driver.internal.core.pool.ChannelPool
- [s0|/127.0.0.2:9042] Error while opening new channel
com.datastax.oss.driver.api.core.connection.ConnectionInitException: [s0|id:
0xab6e686b, L:/127.0.0.1:39342 - R:127.0.0.2/127.0.0.2:9042] Protocol
initialization request, step 1 (STARTUP {CQL_VERSION=3.0.0, DRIVER_
NAME=DataStax Java driver for Apache Cassandra(R), DRIVER_VERSION=4.10.0,
CLIENT_ID=cab7f27e-7c6f-45f3-8d6f-a8f0bde73347}): failed to send request
(io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record:
850068000a0062496e76616c6964206f7220756e737570706f727465642070726f746f636f6c2076657273696f6e20283232293b20737570706f727465642076657273696f6e73206172652028332f76332c20342f76342c20352f76352c20362f763
62d6265746129)
at
com.datastax.oss.driver.internal.core.channel.ProtocolInitHandler$InitRequest.fail(ProtocolInitHandler.java:354)
at
com.datastax.oss.driver.internal.core.channel.ChannelHandlerRequest.writeListener(ChannelHandlerRequest.java:87)
at
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:577)
at
io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:570)
...
{noformat}
These exceptions correspond to the driver attempting to connect to hosts
other than the control connection as discovered via the contents of
system.peers_v2. In the case above port 9042 (native_transport_port, note no
"ssl" in there) is used... which leads to the "not an SSL/TLS record" issues.
Unfortunately I'm seeing the same thing when running a test client against
Brandon's branch. I haven't dug into this in any detail but the cause sure
looks to be the following:
{noformat}
$ ccm status
Cluster: 'cass-402-16999bw-3'
-
node1: UP
node2: UP
node3: UP
$ ccm node1 cqlsh
Connected to cass-409-3 at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.0.9-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh> select * from system.peers_v2; peer | peer_port | data_center |
host_id | native_address | native_port |
native_port_ssl | preferred_ip | preferred_port | rack | release_version |
schema_version | tokens
---+---+-+--++-+-+--++---+-+--+--
127.0.0.3 | 7000 | datacenter1 | 701aa9e6-6a7d-4ec1-9c1e-a103bc56a338 |
127.0.0.3 | 9042 | 9042 | null | null |
rack1 | 4.0.9-SNAPSHOT | 2207c2a9-f598-3971-986b-2926e09e239d |
{'3074457345618258602'}
127.0.0.2 | 7000 | datacenter1 | 3664025a-b102-44f1-a7eb-1a5cd07040d2 |
127.0.0.2 | 9042 | 9042 | null | null |
rack1 | 4.0.9-SNAPSHOT | 2207c2a9-f598-3971
[jira] [Commented] (CASSANDRA-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17812389#comment-17812389 ] Bret McGuire commented on CASSANDRA-16999: -- Bah, this completely slipped off my list. Thanks for the ping [~smiklosovic] ... it's just on me to re-test with the recent changes and confirm we're good. I'll put that back on my list. :) > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803349#comment-17803349 ] Bret McGuire commented on CASSANDRA-19206: -- In ASF Slack the user indicated that they were able to get past the six issue by updating six (although a huge +1 to [~bschoeni] 's suggestion above to upgrade the Python driver version used by cqlsh). They then reported the following errors: ModuleNotFoundError: No module named '[cassandra.io|http://cassandra.io/].libevwrapper' ModuleNotFoundError: No module named 'asyncore' I mentioned this on ASF Slack but I'll repeat it here for discoverability. Python 3.12 completely removed asyncore in favor of asyncio; that's why you see the second error mentioned above. The asyncore reactor is also the default reactor for the Python driver so if you're using Python 3.12 you must specify one of the alternate reactors for your app, and due to some other changes in Python 3.12 this winds up leading to more verbose errors like the ones cited above. These were largely addressed in [PYTHON-1366|https://datastax-oss.atlassian.net/browse/PYTHON-1366] so the new Python driver should behave better here. You will still need to provide an alternate reactor, however. > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.png! > > -- 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-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770211#comment-17770211 ] Bret McGuire commented on CASSANDRA-16999: -- Hey all, apologies for the delay on my end. I'll try to take a look at this over the weekend or early next week! > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- 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-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757802#comment-17757802 ] Bret McGuire commented on CASSANDRA-14667: -- Nope, you have it right [~mmuzaf] . We need to get 3.11.5 out and then this PR can be updated. I'll post an update here once I have a better idea of timelines for a 3.11.5 release but we'll try to make it soon-ish. Also, for the record: [JAVA-3114|https://datastax-oss.atlassian.net/browse/JAVA-3114] is tracking the changes necessary on the driver side. At the moment this is mostly a placeholder for [~mmuzaf] 's PR. > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc > > Time Spent: 1.5h > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- 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-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757098#comment-17757098 ] Bret McGuire commented on CASSANDRA-14667: -- Comments are on the PR itself, but the gist is that we're looking at accepting this shading approach for the short-term and aiming to upgrade dropwizard-metrics inline (and remove the shading) in the longer term. That question pretty quickly leads to a conversation about Java version compatibility with 3.x, and given that that conversation is far from clear at the moment it seemed easier to go with the shaded approach for now and unblock work on 5.x. > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc > > Time Spent: 1.5h > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- 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-14667) Upgrade Dropwizard Metrics to 4.x
[ https://issues.apache.org/jira/browse/CASSANDRA-14667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754755#comment-17754755 ] Bret McGuire commented on CASSANDRA-14667: -- Hey [~e.dimitrova] , I just finished up some other work and started looking at [~mmuzaf] 's PR today. I'll try to get some feedback on there in the next few days or so. > Upgrade Dropwizard Metrics to 4.x > - > > Key: CASSANDRA-14667 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14667 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Stig Rohde Døssing >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Attachments: signature.asc > > Time Spent: 1.5h > Remaining Estimate: 0h > > Cassandra currently uses Metrics 3.1.5. Version 4.0.0 added some fixes for > Java 9 compatibility. It would be good to upgrade the Metrics library as part > of the version of Cassandra that adds Java 9 compatibility > (https://issues.apache.org/jira/browse/CASSANDRA-9608). -- 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-18504) Added support for type VECTOR
[ https://issues.apache.org/jira/browse/CASSANDRA-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17727613#comment-17727613 ] Bret McGuire commented on CASSANDRA-18504: -- A note on the serialization format: right now we're serializing vectors as just a sequence of the underlying subtypes. So if we have a vector of floats of dimension 3 we just write three serialized floats one after another on the wire; there's no size information included for either the number of elements in the list or the size of any one element. This differs from how other collections (such as lists and maps) and UDTs are handled. In those cases we send along (a) the element size of a given collection and (b) the size of each element (included in the bytes structure). Such a change isn't unreasonable, at least not for fixed size types (and perhaps the variable types as well) since hypothetically the codecs should be aware of how big a given type might be. But that's not what, say, the Java driver does at the moment. Let's take the example of a float type; when decoding a ByteBuffer expected to contain an instance of this type we expect that ByteBuffer to contain precisely four bytes. The assumption is that something upstream has pulled off exactly the expected number of bytes from some larger ByteBuffer. I certainly can take steps to expose the expected number of bytes for a given codec. But it did seem worthwhile to highlight the difference and make sure that this difference in serialization formats represents an explicit choice. > Added support for type VECTOR > -- > > Key: CASSANDRA-18504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18504 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema, CQL/Syntax >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 5.5h > Remaining Estimate: 0h > > Based off several mailing list threads (see "[POLL] Vector type for ML”, > "[DISCUSS] New data type for vector search”, and "Adding vector search to SAI > with heirarchical navigable small world graph index”), its desirable to add a > new type “VECTOR” that has the following properties > 1) fixed length array > 2) elements may not be null > 3) flatten array (aka multi-cell = false) -- 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-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17543158#comment-17543158
]
Bret McGuire commented on CASSANDRA-17411:
--
Hey [~brandon.williams] , I had to dig into this a bit for a related issue with
the Python driver and I came up with some additional info which might be
useful. After looking into this it sure looks like this might be a server-side
issue after all... but obviously I'll defer to you on that part. :)
Based on my testing I confirmed the following things about the LBPs in use by
app.py when running against Cassandra 4.0.3:
* When iptables is used to shut down access to one of the IP addresses the
load balancing policy (LBP) in use by the client is notified that the node has
gone down
* As expected that LBP then removes the down node from it’s collection of
“live” nodes for the given DC
* The LBP no longer returns the down node when make_query_plan() is called
Great, but by itself that doesn't prove anything. So I decided to take a look
at the exceptions that were actually getting thrown in this case. With the
following change to app.py:
{code:java}
55c55,59
< except (cassandra.OperationTimedOut, cassandra.WriteTimeout):
---
> except cassandra.OperationTimedOut as exc:
> LOG.info(exc)
> timeout_counter += 1
> except cassandra.WriteTimeout as exc:
> LOG.info(exc) {code}
I see a sequence of two different error messages when I drop the iptables
hammer. The first is a set of "Client request timeout" messages (which is
entirely expected since the LBP doesn't know about the down node yet) while the
second looks to be a server-side issue:
{code:java}
2022-05-27 22:01:38,629 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
2022-05-27 22:01:48,734 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
2022-05-27 22:01:58,845 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
2022-05-27 22:02:03,954 - target-dc1 - __main__ - INFO - Error from server:
code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'consistency':
'ONE', 'required_responses': 1, 'received_responses': 0, 'write_type':
'COUNTER'}
2022-05-27 22:02:14,172 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
2022-05-27 22:02:22,545 - target-dc3 - __main__ - INFO - Got 0/579 (0.00)
timeouts/total_rqs in the last 1 minute
2022-05-27 22:02:22,548 - target-dc2 - __main__ - INFO - Got 0/579 (0.00)
timeouts/total_rqs in the last 1 minute
2022-05-27 22:02:24,275 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
2022-05-27 22:02:24,376 - target-dc1 - __main__ - INFO - Got 6/66 (9.090909)
timeouts/total_rqs in the last 1 minute
2022-05-27 22:02:34,387 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
2022-05-27 22:02:44,695 - target-dc1 - __main__ - INFO -
errors={'127.0.0.1:9042': 'Client request timeout. See
Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042 {code}
When the LBP gets notified of the down node things change; the "Client request
timeout" disappears and all I see is the server-side issue:
{code:java}
2022-05-27 22:02:52,482 - target-dc1 - cassandra.cluster - WARNING - Host
127.0.0.1:9042 has been marked down
2022-05-27 22:02:52,483 - target-dc1 - cassandra.policies - INFO - on_down for
host 127.0.0.1:9042
2022-05-27 22:02:52,485 - target-dc1 - cassandra.policies - INFO - Setting
hosts for dc dc1 to (,)
2022-05-27 22:02:52,486 - target-dc1 - cassandra.policies - INFO - on_down for
host 127.0.0.1:9042
2022-05-27 22:02:52,488 - target-dc1 - cassandra.policies - INFO - on_down for
host 127.0.0.1:9042
2022-05-27 22:02:52,488 - target-dc1 - cassandra.policies - INFO - on_down for
host 127.0.0.1:9042
2022-05-27 22:02:57,50
[jira] [Commented] (CASSANDRA-16999) system.peers and system.peers_v2 do not contain the native_transport and/or native_transport_port_ssl
[ https://issues.apache.org/jira/browse/CASSANDRA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541811#comment-17541811 ] Bret McGuire commented on CASSANDRA-16999: -- Apologies for the late response [~brandon.williams] , I must've completely missed the notification on this. For the record the fix for the Java driver is in [JAVA-2967|https://datastax-oss.atlassian.net/browse/JAVA-2967]. The corresponding PR did add support for extracting these values from system.peers columns; the IP address comes from "native_transport_address" while port info (initially) comes from "native_transport_port". But if we're configured to use SSL connections we'll override port info with what's in "native_transport_port_ssl". The Java driver will still support "native_address" and "native_port" as well (and in fact those values are checked before "native_transport_*"). Problem there is that a single port value doesn't cleanly express the unencrypted and encrypted ports. > system.peers and system.peers_v2 do not contain the native_transport and/or > native_transport_port_ssl > - > > Key: CASSANDRA-16999 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16999 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Steve Lacerda >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.x > > > system.peers_v2 includes a “native_port” but has no notion of > native_transport_port vs. native_transport_port_ssl. Given this limited > information, there’s no clear way for the driver to know that different ports > are being used for SSL vs. non-SSL or which of those two ports is identified > by “native_port”. > > The issue we ran into is that the java driver, since it has no notion of the > transport port SSL, the driver was only using the contact points and was not > load balancing. > > The customer had both set: > native_transport_port: 9042 > native_transport_port_ssl: 9142 > > They were attempting to connect to 9142, but that was failing. They could > only use 9042, and so their applications load balancing was failing. We found > that any node that was a contact point was connecting, but the other nodes > were never acting as coordinators. > > There are still issues in the driver, for which I have created JAVA-2967, > which also refers to JAVA-2638, but the system.peers and system.peers_v2 > tables should both contain native_transport_port and > native_transport_port_ssl. > > -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
