[jira] [Updated] (CASSANDRA-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17879:
--
Status: Needs Committer (was: Review In Progress)
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(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-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17879:
--
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.1.x
4.x
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(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-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612491#comment-17612491
]
Stefan Miklosovic commented on CASSANDRA-17879:
---
[~brandon.williams] would you mind to take a look, please?
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(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-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612490#comment-17612490
]
Stefan Miklosovic commented on CASSANDRA-17879:
---
branches
3.0 [https://github.com/instaclustr/cassandra/tree/cassandra-3.0]
3.11 [https://github.com/instaclustr/cassandra/tree/cassandra-3.11]
4.0 [https://github.com/instaclustr/cassandra/tree/cassandra-4.0]
4.1[https://github.com/instaclustr/cassandra/tree/cassandra-4.1]
trunk [https://github.com/instaclustr/cassandra/tree/trunk]
builds
3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1965/]
3.11
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1966/]
4.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1967/]
4.1 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1969/]
trunk
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1971/]
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(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-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612490#comment-17612490
]
Stefan Miklosovic edited comment on CASSANDRA-17879 at 10/4/22 6:50 AM:
branches
3.0 [https://github.com/instaclustr/cassandra/tree/cassandra-3.0]
3.11 [https://github.com/instaclustr/cassandra/tree/cassandra-3.11]
4.0 [https://github.com/instaclustr/cassandra/tree/cassandra-4.0]
4.1[https://github.com/instaclustr/cassandra/tree/cassandra-4.1]
trunk [https://github.com/instaclustr/cassandra/tree/trunk]
builds
3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1965/]
3.11
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1966/]
4.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1967/]
4.1 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1969/]
trunk
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1971/]
was (Author: smiklosovic):
branches
3.0 [https://github.com/instaclustr/cassandra/tree/cassandra-3.0]
3.11 [https://github.com/instaclustr/cassandra/tree/cassandra-3.11]
4.0 [https://github.com/instaclustr/cassandra/tree/cassandra-4.0]
4.1[https://github.com/instaclustr/cassandra/tree/cassandra-4.1]
trunk [https://github.com/instaclustr/cassandra/tree/trunk]
builds
3.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1965/]
3.11
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1966/]
4.0 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1967/]
4.1 [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1969/]
trunk
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1971/]
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (2242cf98 -> f096b75f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit 2242cf98 generate docs for 2af01b8f new f096b75f generate docs for 2af01b8f This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (2242cf98) \ N -- N -- N refs/heads/asf-staging (f096b75f) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-17005:
---
Assignee: (was: Berenguer Blasi)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ... log.exception("Operation
> failed
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17005:
Resolution: (was: Not A Problem)
Status: Open (was: Resolved)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # proces
[jira] [Updated] (CASSANDRA-16640) Round out cqlsh completion test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-16640: --- Component/s: CQL/Interpreter > Round out cqlsh completion test coverage > > > Key: CASSANDRA-16640 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16640 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter, Test/unit >Reporter: Adam Holmberg >Assignee: Brad Schoening >Priority: Low > Fix For: 4.0.x > > > There are some missing tests in cqlsh completion. Some highlighted > [here|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/test/test_cqlsh_completion.py#L808-L824]. > There might be more needing coverage that are not enumerated. -- This message was sent by Atlassian Jira (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-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612469#comment-17612469
]
Brad Schoening commented on CASSANDRA-17879:
[~smiklosovic] thanks, I took a look at the link, but it wasn't immediately
clear. I'll take a more in depth look at it soon and cherry picking.
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(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-17946) Upgrade back Mockito to 4.7.0 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Fix Version/s: 4.2 (was: 4.x) Since Version: 4.1-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/719d1948df827e864ff66e44e22c7fad334c3100 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 > --- > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.2 > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 4.7.0 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Since Version: (was: 4.1-alpha1) > Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 > --- > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.2 > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 4.7.0 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612459#comment-17612459 ] Ekaterina Dimitrova commented on CASSANDRA-17946: - To https://github.com/apache/cassandra.git [35578a4a9f..719d1948df trunk -> trunk|https://github.com/apache/cassandra/commit/719d1948df827e864ff66e44e22c7fad334c3100] Thanks! > Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 > --- > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Revert Mockito downgrade from CASSANDRA-17750 patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Abe Ratnofsky for CASSANDRA-17946
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new 719d1948df Revert Mockito downgrade from CASSANDRA-17750 patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Abe Ratnofsky for CASSANDRA-17946 719d1948df is described below commit 719d1948df827e864ff66e44e22c7fad334c3100 Author: Ekaterina Dimitrova AuthorDate: Mon Oct 3 16:37:00 2022 -0400 Revert Mockito downgrade from CASSANDRA-17750 patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Abe Ratnofsky for CASSANDRA-17946 --- .build/parent-pom-template.xml | 2 +- CHANGES.txt| 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/.build/parent-pom-template.xml b/.build/parent-pom-template.xml index 73a6431408..b288221e49 100644 --- a/.build/parent-pom-template.xml +++ b/.build/parent-pom-template.xml @@ -452,7 +452,7 @@ org.mockito mockito-core -3.2.4 +4.7.0 test diff --git a/CHANGES.txt b/CHANGES.txt index f35e0fe599..7674033702 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.2 + * Revert Mockito downgrade from CASSANDRA-17750 (CASSANDRA-17496) * Add --older-than and --older-than-timestamp options for nodetool clearsnapshots (CASSANDRA-16860) * Fix "open RT bound as its last item" exception (CASSANDRA-17810) * Fix leak of non-standard Java types in JMX MBeans `org.apache.cassandra.db:type=StorageService` - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17946) Upgrade back Mockito to 4.7.0 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612458#comment-17612458 ] Ekaterina Dimitrova commented on CASSANDRA-17946: - There is only one known failure (CASSANDRA-17005), starting commit soon. > Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 > --- > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 4.7.0 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Status: Ready to Commit (was: Review In Progress) > Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 > --- > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612457#comment-17612457
]
Ekaterina Dimitrova commented on CASSANDRA-17005:
-
I think this one fails pretty consistently in CircleCI, like almost every other
time, and the other ticket seems to me to be focused on the Jenkins endless
timeouts.
I would advocate to just reopen this one.
In other news, just saw it again, trunk:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1975/workflows/9dfad996-8e8f-497e-b01a-4d9212540646/jobs/15657
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.1
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout i
[jira] [Updated] (CASSANDRA-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17923: -- Change Category: Operability Complexity: Normal Component/s: Messaging/Internode Status: Open (was: Triage Needed) > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (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-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17923: -- Status: Patch Available (was: Open) > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (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-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17923: -- Status: Review In Progress (was: Patch Available) > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Internode >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (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-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612454#comment-17612454 ] Yifan Cai commented on CASSANDRA-17923: --- The code looks good to me and the CI is green. +1 on the patch. > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (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-17702) Fix flaky dtest - repair_tests.repair_test.TestRepair.test_dead_sync_initiator
[
https://issues.apache.org/jira/browse/CASSANDRA-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612453#comment-17612453
]
Ekaterina Dimitrova commented on CASSANDRA-17702:
-
Looking into Jenkins it seems there was particular particular time when this
test started failing
Last green was from CASSANDRA-17524,
[#271|https://ci-cassandra.apache.org/job/Cassandra-3.0/271/testReport/dtest.repair_tests.repair_test/TestRepair/]
is the first Jenkins run when we see it failing, the legacy parsing fix from
CASSANDRA-17581
There were also some fixes applied in the DTest repo somewhere in that time
which revealed long time issues so probably worth to check that too.
> Fix flaky dtest - repair_tests.repair_test.TestRepair.test_dead_sync_initiator
> --
>
> Key: CASSANDRA-17702
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17702
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest-novnode.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] "ERROR [RepairJobTask:4] 2022-06-19 17:51:47,864
> SystemDistributedKeyspace.java:324 - Error executing query UPDATE
> system_distributed.repair_history SET status = 'FAILED', finished_at =
> toTimestamp(now()), exception_message=?, exception_stacktrace=? WHERE
> keyspace_name = 'keyspace1' AND columnfamily_name = 'standard1' AND id =
> 75f1ee00-eff8-11ec-ad59-710cf5e63782\njava.lang.AssertionError:
> java.lang.InterruptedException\n\tat
> org.apache.cassandra.net.OutboundTcpConnection.enqueue(OutboundTcpConnection.java:187)\n\tat
>
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:956)\n\tat
>
> org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:918)\n\tat
>
> org.apache.cassandra.service.StorageProxy.sendToHintedEndpoints(StorageProxy.java:1425)\n\tat
>
> org.apache.cassandra.service.StorageProxy$2.apply(StorageProxy.java:142)\n\tat
>
> org.apache.cassandra.service.StorageProxy.performWrite(StorageProxy.java:1203)\n\tat
>
> org.apache.cassandra.service.StorageProxy.mutate(StorageProxy.java:740)\n\tat
> org.apache.cassandra.service.StorageProxy.mutateWithTriggers(StorageProxy.java:972)\n\tat
>
> org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:435)\n\tat
>
> org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:421)\n\tat
>
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:243)\n\tat
>
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:274)\n\tat
>
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:289)\n\tat
>
> org.apache.cassandra.repair.SystemDistributedKeyspace.processSilent(SystemDistributedKeyspace.java:320)\n\tat
>
> org.apache.cassandra.repair.SystemDistributedKeyspace.failedRepairJob(SystemDistributedKeyspace.java:254)\n\tat
> org.apache.cassandra.repair.RepairJob$3.onFailure(RepairJob.java:132)\n\tat
> com.google.common.util.concurrent.Futures$6.run(Futures.java:1313)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.lang.InterruptedException: null\n\tat
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220)\n\tat
>
> java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:335)\n\tat
>
> java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:339)\n\tat
>
> org.apache.cassandra.net.OutboundTcpConnection.enqueue(OutboundTcpConnection.java:183)\n\t...
> 20 common frames omitted"]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyothsna Konisa updated CASSANDRA-17923: Test and Documentation Plan: Added test cases to test internode TLS support for scenarios like rolling updates. Also tested this TLS mixed mode operation using CCM locally. [https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=mixmode-internode-auth] [https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=mixmode-internode-auth] was: Added test cases to test internode TLS support for scenarios like upgrading and downgrading clusters. Also tested this TLS mixed mode operation using CCM locally. [https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=mixmode-internode-auth] [https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=mixmode-internode-auth] > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (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-17923) Mixed mode support for internode authentication during TLS upgrades
[ https://issues.apache.org/jira/browse/CASSANDRA-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyothsna Konisa updated CASSANDRA-17923: Reviewers: Jon Meredith, Yifan Cai Source Control Link: https://github.com/apache/cassandra/pull/1884 Test and Documentation Plan: Added test cases to test internode TLS support for scenarios like upgrading and downgrading clusters. Also tested this TLS mixed mode operation using CCM locally. [https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=mixmode-internode-auth] [https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra?branch=mixmode-internode-auth] Tester: Jyothsna Konisa > Mixed mode support for internode authentication during TLS upgrades > --- > > Key: CASSANDRA-17923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17923 > Project: Cassandra > Issue Type: New Feature >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > During upgrades from "non-ssl -> ssl" or "ssl-mTLS" the cluster should be > able to function in mixed mode with some nodes supporting "non-ssl" > authentication and the new nodes supporting "mTLS" authentication. Currently > we do not have this supported and because of which upgrades are not possible > for upgrading internode authentication strategies. > If a node is configured in optional mode for internode connections, retry > with other SSL strategies If the node is not able to connect to other nodes > due to authentication problems. -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 4.7.0 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Summary: Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 (was: Upgrade back Mockito to 1.12.13 after CASSANDRA-17750) > Upgrade back Mockito to 4.7.0 after CASSANDRA-17750 > --- > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Reviewers: Abe Ratnofsky, Michael Semb Wever (was: Abe Ratnofsky, Ekaterina Dimitrova, Michael Semb Wever) > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Reviewers: Abe Ratnofsky, Michael Semb Wever, Ekaterina Dimitrova Abe Ratnofsky, Michael Semb Wever, Ekaterina Dimitrova (was: Abe Ratnofsky, Ekaterina Dimitrova, Michael Semb Wever) Status: Review In Progress (was: Patch Available) > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Description: Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to 1.12.13) happened in CASSANDRA-17835 It seems during rebase in the next commit some changes were discarded: Mockito was downgraded back to 3.2.4. We need to fix this. The other two dependencies are at the right version. CC [~aratnofsky] , [~dcapwell] and [~mck] was: Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to 1.12.13) happened in CASSANDRA-17835 It seems during rebase in the next commit some changes were discarded: mockito was downgraded back to 1.10.10. We need to fix this. The other two dependencies are at the right version. CC [~aratnofsky] , [~dcapwell] and [~mck] > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > Mockito was downgraded back to 3.2.4. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[
https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612449#comment-17612449
]
Ekaterina Dimitrova commented on CASSANDRA-17946:
-
{quote}think you mean mockito was downgraded back to 3.2.4
{quote}
Definitely :) Corrected the description, thanks :)
> Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
> -
>
> Key: CASSANDRA-17946
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17946
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to
> 1.12.13) happened in CASSANDRA-17835
> It seems during rebase in the next commit some changes were discarded:
> Mockito was downgraded back to 3.2.4.
> We need to fix this. The other two dependencies are at the right version.
> CC [~aratnofsky] , [~dcapwell] and [~mck]
--
This message was sent by Atlassian Jira
(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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612448#comment-17612448 ] Michael Semb Wever commented on CASSANDRA-17946: +1 > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612447#comment-17612447 ] Michael Semb Wever commented on CASSANDRA-17946: > mockito was downgraded back to 1.10.10. think you mean mockito was downgraded back to 3.2.4 > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612446#comment-17612446 ] Ekaterina Dimitrova commented on CASSANDRA-17946: - No worries, I can see how that quietly happened with the addition of the new separate pom files. :) Thank you for the review, I forgot to raise the resources and of course the Python tests "exploded" Second try [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=trunk-17946], #1975 > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612445#comment-17612445
]
Ekaterina Dimitrova commented on CASSANDRA-17947:
-
Sure, as we talked in Slack, it doesn't cause any issues, it was more about the
house cleaning. I will keep the ticket open for awareness so that someone else
doesn't remove it without asking. Feel free to update/use it for your work if
you want [~bdeggleston]. Thanks
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612445#comment-17612445
]
Ekaterina Dimitrova edited comment on CASSANDRA-17947 at 10/3/22 10:01 PM:
---
Sure, as we talked in Slack, it doesn't cause any issues, it was more about the
house cleaning. I will keep the ticket open for awareness so that someone else
doesn't remove target&dependency without asking. Feel free to update/use it for
your work if you want [~bdeggleston]. Thanks
was (Author: e.dimitrova):
Sure, as we talked in Slack, it doesn't cause any issues, it was more about the
house cleaning. I will keep the ticket open for awareness so that someone else
doesn't remove it without asking. Feel free to update/use it for your work if
you want [~bdeggleston]. Thanks
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612441#comment-17612441 ] Abe Ratnofsky commented on CASSANDRA-17946: --- Thanks for catching [~e.dimitrova] – that's unfortunate timing on the rebase. Patch LGTM. > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612440#comment-17612440
]
Blake Eggleston edited comment on CASSANDRA-17947 at 10/3/22 9:20 PM:
--
I'd prefer we keep this around for now if it's not causing any issues for us. I
do intend to come back to allocation optimization at some point, and even have
some unfinished work removing most allocation from the read path that I'd like
to get back to after accord has shipped.
was (Author: bdeggleston):
I'd prefer we keep this around for now if it's now causing any issues for us. I
do intend to come back to allocation optimization at some point, and even have
some unfinished work removing most allocation from the read path that I'd like
to get back to after accord has shipped.
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612440#comment-17612440
]
Blake Eggleston commented on CASSANDRA-17947:
-
I'd prefer we keep this around for now if it's now causing any issues for us. I
do intend to come back to allocation optimization at some point, and even have
some unfinished work removing most allocation from the read path that I'd like
to get back to after accord has shipped.
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612439#comment-17612439
]
Ekaterina Dimitrova commented on CASSANDRA-17947:
-
Versions to be confirmed whether we want it only in trunk or also to clean the
already released versions
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17947:
Description:
I noticed the {{test-memory}} target which seems to have been added in
CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_ which
was added as a dependency was not really maintained by the authors. I think
this is the official repo - [https://github.com/google/allocation-instrumenter]
and last commit was to support Java 8 in 2020. The test itself was also not
added to CI.
Confirmed with [~dcapwell] in Slack
CC [~bdeggleston] and [~benedict]
was:
I noticed the {{test-memory}} target which seems to have been added in
CASSANDRA-15388. Unfortunately, since then{{ java-allocation-instrumenter
}}which was added as a dependency was not really maintained by the authors. I
think this is the official repo -
[https://github.com/google/allocation-instrumenter] and last commit was to
support Java 8 in 2020. The test itself was also not added to CI.
Confirmed with [~dcapwell] in Slack
CC [~bdeggleston] and [~benedict]
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then _java-allocation-instrumenter_
> which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
[
https://issues.apache.org/jira/browse/CASSANDRA-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17947:
Change Category: Quality Assurance
Complexity: Low Hanging Fruit
Component/s: Build
Fix Version/s: 4.0.x
4.1.x
4.x
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Remove test-memory target
> -
>
> Key: CASSANDRA-17947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> I noticed the {{test-memory}} target which seems to have been added in
> CASSANDRA-15388. Unfortunately, since then{{ java-allocation-instrumenter
> }}which was added as a dependency was not really maintained by the authors. I
> think this is the official repo -
> [https://github.com/google/allocation-instrumenter] and last commit was to
> support Java 8 in 2020. The test itself was also not added to CI.
> Confirmed with [~dcapwell] in Slack
> CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17947) Remove test-memory target
Ekaterina Dimitrova created CASSANDRA-17947:
---
Summary: Remove test-memory target
Key: CASSANDRA-17947
URL: https://issues.apache.org/jira/browse/CASSANDRA-17947
Project: Cassandra
Issue Type: Task
Reporter: Ekaterina Dimitrova
I noticed the {{test-memory}} target which seems to have been added in
CASSANDRA-15388. Unfortunately, since then{{ java-allocation-instrumenter
}}which was added as a dependency was not really maintained by the authors. I
think this is the official repo -
[https://github.com/google/allocation-instrumenter] and last commit was to
support Java 8 in 2020. The test itself was also not added to CI.
Confirmed with [~dcapwell] in Slack
CC [~bdeggleston] and [~benedict]
--
This message was sent by Atlassian Jira
(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-17946) Upgrade back Mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Summary: Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 (was: Upgrade back mockito to 1.12.13 after CASSANDRA-17750) > Upgrade back Mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612432#comment-17612432 ] Ekaterina Dimitrova commented on CASSANDRA-17946: - [patch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:trunk-17946?expand=1]. CI started [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=trunk-17946] > Upgrade back mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Test and Documentation Plan: [Patch|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:trunk-17946?expand=1]. CI started [here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=trunk-17946] No new tests added, current CI to be validated Status: Patch Available (was: In Progress) > Upgrade back mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Fix Version/s: 4.x > Upgrade back mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (e56fefee -> 2242cf98)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard e56fefee generate docs for 9a83b59d
add c79906b7 CASSANDRA-17860 Center dirty intervals image
add 2af01b8f Apache Cassandra Changelog #19
add 2242cf98 generate docs for 2af01b8f
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (e56fefee)
\
N -- N -- N refs/heads/asf-site (2242cf98)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
content/_/_images/blog/Dirty-intervals.png | Bin 38012 -> 19668 bytes
content/_/_images/blog/gracehopperOSD.png | Bin 0 -> 846322 bytes
content/_/blog.html| 24
...che-Cassandra-Changelog-19-September-2022.html} | 117 +--
content/search-index.js| 2 +-
.../modules/ROOT/images/blog/Dirty-intervals.png | Bin 38012 -> 19668 bytes
.../modules/ROOT/images/blog/gracehopperOSD.png| Bin 0 -> 846322 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24
...ache-Cassandra-Changelog-19-September-2022.adoc | 127 +
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
10 files changed, 232 insertions(+), 62 deletions(-)
create mode 100644 content/_/_images/blog/gracehopperOSD.png
copy content/_/blog/{Apache-Cassandra-Changelog-18-August-2022.html =>
Apache-Cassandra-Changelog-19-September-2022.html} (61%)
create mode 100644
site-content/source/modules/ROOT/images/blog/gracehopperOSD.png
create mode 100644
site-content/source/modules/ROOT/pages/blog/Apache-Cassandra-Changelog-19-September-2022.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17946) Upgrade back mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Description: Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to 1.12.13) happened in CASSANDRA-17835 It seems during rebase in the next commit some changes were discarded: mockito was downgraded back to 1.10.10. We need to fix this. The other two dependencies are at the right version. CC [~aratnofsky] , [~dcapwell] and [~mck] was: Update of ASM(9.1 to 9.3), Mockito(1.10.10 to 1.12.13) and ByteBuddy(3.2.4 to 4.7.0) happened in CASSANDRA-17835 It seems during rebase in the next commit some changes were discarded: mockito was downgraded back to 1.10.10. We need to fix this. The other two dependencies are at the right version. CC [~aratnofsky] , [~dcapwell] and [~mck] > Upgrade back mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Update of ASM(9.1 to 9.3), Mockito(3.2.4 to 4.7.0) and ByteBuddy(1.10.10 to > 1.12.13) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back mockito to 1.12.13 after CASSANDRA-17750
[ https://issues.apache.org/jira/browse/CASSANDRA-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17946: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Build Discovered By: User Report Severity: Normal Assignee: Ekaterina Dimitrova Status: Open (was: Triage Needed) > Upgrade back mockito to 1.12.13 after CASSANDRA-17750 > - > > Key: CASSANDRA-17946 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Update of ASM(9.1 to 9.3), Mockito(1.10.10 to 1.12.13) and ByteBuddy(3.2.4 to > 4.7.0) happened in CASSANDRA-17835 > It seems during rebase in the next commit some changes were discarded: > mockito was downgraded back to 1.10.10. > We need to fix this. The other two dependencies are at the right version. > CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17946) Upgrade back mockito to 1.12.13 after CASSANDRA-17750
Ekaterina Dimitrova created CASSANDRA-17946: --- Summary: Upgrade back mockito to 1.12.13 after CASSANDRA-17750 Key: CASSANDRA-17946 URL: https://issues.apache.org/jira/browse/CASSANDRA-17946 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova Update of ASM(9.1 to 9.3), Mockito(1.10.10 to 1.12.13) and ByteBuddy(3.2.4 to 4.7.0) happened in CASSANDRA-17835 It seems during rebase in the next commit some changes were discarded: mockito was downgraded back to 1.10.10. We need to fix this. The other two dependencies are at the right version. CC [~aratnofsky] , [~dcapwell] and [~mck] -- This message was sent by Atlassian Jira (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-17945) StorageService.getNativeaddress does not account for IPv6 addresses in the case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
Andy Tolbert created CASSANDRA-17945:
Summary: StorageService.getNativeaddress does not account for IPv6
addresses in the case NATIVE_ADDRESS_AND_PORT is not present in gossip state
for an endpoint
Key: CASSANDRA-17945
URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
Project: Cassandra
Issue Type: Improvement
Components: Cluster/Gossip
Reporter: Andy Tolbert
Assignee: Andy Tolbert
While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
following in logs for upgraded nodes when processing down events for 3.0 nodes
that are going down as part of an upgrade:
{noformat}
2022-09-28 20:18:48,244 ERROR [GossipStage:1]
org.apache.cassandra.transport.Server - Problem retrieving RPC address for
/[0:0:0:0:0:0:0:d9]:7000
java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
at
org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
at
org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
at
org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
at org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
at
org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
at org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
at
org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
at
org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.58.Final.jar:4.1.58.Final]
at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
It appears that StorageService.getNativeaddress does not account for the fact
that an endpoint may be an IPv6 address, which required brackets when specified
with a port:
[https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
{code:java}
/**
* Return the native address associated with an endpoint as a string.
* @param endpoint The endpoint to get rpc address for
* @return the native address
*/
public String getNativeaddress(InetAddressAndPort endpoint, boolean
withPort)
{
if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
return
FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
else if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
!= null)
{
try
{
InetAddressAndPort address =
InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
return address.getHostAddress(withPort);
}
catch (UnknownHostException e)
{
throw new RuntimeException(e);
}
}
else if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
== null)
return endpoint.address.getHostAddress() + ":" +
DatabaseDescriptor.getNativeTransportPort();
else
return
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value
+ ":" + DatabaseDescriptor.getNativeTransportPort();
}{code}
In the two final else cases, the endpoint address and port are delimited with a
colon. For IPv6 addresses this creates an invalid address
(0:0:0:0:0:0:0:d9:9042), IPv6 addresses must be enclosed in brackets (e.g.
[0:0:0:0:0:0:0:d9]:9042) per
[https://datatracker.ietf.org/doc/html/rfc2732#section-2]
Once a cluster is fully upgraded to 4.0, this error no longer occurs as all
endpoints will have N
[jira] [Commented] (CASSANDRA-17915) Confusing error message when using ? with functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612394#comment-17612394
]
Natnael Adere commented on CASSANDRA-17915:
---
This is the pull request for the patch:
https://github.com/apache/cassandra/pull/1889
> Confusing error message when using ? with functions
> ---
>
> Key: CASSANDRA-17915
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17915
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: David Capwell
>Assignee: Natnael Adere
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> INSERT INTO %S (a, b, c) VALUES (? + 1, ?, ?)
> {code}
> Errors saying
> {code}
> Ambiguous '+' operation with args ? and 1: use type casts to disambiguate
> {code}
> Now, if you google “type casts CQL” you get
> https://docs.datastax.com/en/dse/5.1/cql/cql/cql_reference/refCqlFunction.html
> which says to do
> {code}
> CAST( selector AS to_type )
> {code}
> But this also fails!
> {code}
> InvalidRequestException: Ambiguous call to function system.castAsFloat (can
> be matched by following signatures: system."castAsFloat" : (bigint) -> float,
> system."castAsFloat" : (counter) -> float, system."castAsFloat" : (double) ->
> float, system."castAsFloat" : (int) -> float, system."castAsFloat" :
> (tinyint) -> float, system."castAsFloat" : (varint) -> float,
> system."castAsFloat" : (decimal) -> float, system."castAsFloat" : (smallint)
> -> float): use type casts to disambiguate
> {code}
> What we have to do is
> {code}
> INSERT INTO %S (a, b, c) VALUES ((int) ? + 1, ?, ?)
> {code}
> We should improve the error message to show the expected syntax (or fix CAST
> to work in this case).
--
This message was sent by Atlassian Jira
(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-17240) CEP-19: Trie memtable implementation
[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612376#comment-17612376
]
Caleb Rackliffe commented on CASSANDRA-17240:
-
Ah, and I almost forgot...
Prepended to the actual trie stuff is a commit that changes some of the
memtable heap space accounting. It seems like there are things that we're now
ignoring ({{Owner}}, {{MemtableAllocator}}, and initial comparator in
{{AbstractAllocatorMemtable}}; empty clusterings; and the
{{measureDeepOmitShared()}}) and would push flush frequency down a bit, but
then the changes in {{Columns}} potentially pushing flush frequency up. Do we
have an idea of where that nets out?
> CEP-19: Trie memtable implementation
>
>
> Key: CASSANDRA-17240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17240
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Normal
> Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png,
> density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png,
> latency-9_1-95.png, throughput_SG.png, throughput_apache.png
>
> Time Spent: 10h 50m
> Remaining Estimate: 0h
>
> Trie-based memtable implementation as described in CEP-19, built on top of
> CASSANDRA-17034 and CASSANDRA-6936.
> The implementation is available in this
> [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240].
--
This message was sent by Atlassian Jira
(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-16681) org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
[ https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612364#comment-17612364 ] Aleksey Yeschenko commented on CASSANDRA-16681: --- First 6 out of 7 commits look good to me. Some nice catches there. Almost done convincing myself that the changes in the very last commit - "Fix and simplify chunk status management" - is safe. Won't be long now, and my apologies for the delay again. > org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky > -- > > Key: CASSANDRA-16681 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16681 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Piotr Kolaczkowski >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins history: > [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/] > Fails being run in a loop in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008 > -- This message was sent by Atlassian Jira (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-17944) Extend testing for Python DTest test_sstableupgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17944:
Summary: Extend testing for Python DTest test_sstableupgrade (was: Extend
testing for test_sstableupgrade)
> Extend testing for Python DTest test_sstableupgrade
> ---
>
> Key: CASSANDRA-17944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17944
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> While looking into another problem I noticed the below comment and I did not
> find expansion of this coverage, the particular test still ends in 3.X. Maybe
> we test in the in-jvm? To be checked.
> {code:java}
> # 4.0 removes back compatibility with pre-3.0 versions, so testing
> upgradesstables for
> # paths from those versions to 4.0 is invalid (and can only fail). There
> isn't currently
> # any difference between the 3.0 and 4.0 sstable format though, but when the
> version is
> # bumped for 4.0, remove the max_version & add a case for testing a 3.0 ->
> 4.0 upgrade
> @since('2.2', max_version='3.X')
> def test_sstableupgrade(self):{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17944) Extend testing for test_sstableupgrade
Ekaterina Dimitrova created CASSANDRA-17944:
---
Summary: Extend testing for test_sstableupgrade
Key: CASSANDRA-17944
URL: https://issues.apache.org/jira/browse/CASSANDRA-17944
Project: Cassandra
Issue Type: Task
Reporter: Ekaterina Dimitrova
While looking into another problem I noticed the below comment and I did not
find expansion of this coverage, the particular test still ends in 3.X. Maybe
we test in the in-jvm? To be checked.
{code:java}
# 4.0 removes back compatibility with pre-3.0 versions, so testing
upgradesstables for
# paths from those versions to 4.0 is invalid (and can only fail). There isn't
currently
# any difference between the 3.0 and 4.0 sstable format though, but when the
version is
# bumped for 4.0, remove the max_version & add a case for testing a 3.0 -> 4.0
upgrade
@since('2.2', max_version='3.X')
def test_sstableupgrade(self):{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17944) Extend testing for test_sstableupgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17944:
Fix Version/s: 4.x
4.0.x
4.1.x
> Extend testing for test_sstableupgrade
> --
>
> Key: CASSANDRA-17944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17944
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> While looking into another problem I noticed the below comment and I did not
> find expansion of this coverage, the particular test still ends in 3.X. Maybe
> we test in the in-jvm? To be checked.
> {code:java}
> # 4.0 removes back compatibility with pre-3.0 versions, so testing
> upgradesstables for
> # paths from those versions to 4.0 is invalid (and can only fail). There
> isn't currently
> # any difference between the 3.0 and 4.0 sstable format though, but when the
> version is
> # bumped for 4.0, remove the max_version & add a case for testing a 3.0 ->
> 4.0 upgrade
> @since('2.2', max_version='3.X')
> def test_sstableupgrade(self):{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17944) Extend testing for test_sstableupgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17944:
Change Category: Quality Assurance
Complexity: Normal
Component/s: CI
Status: Open (was: Triage Needed)
> Extend testing for test_sstableupgrade
> --
>
> Key: CASSANDRA-17944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17944
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> While looking into another problem I noticed the below comment and I did not
> find expansion of this coverage, the particular test still ends in 3.X. Maybe
> we test in the in-jvm? To be checked.
> {code:java}
> # 4.0 removes back compatibility with pre-3.0 versions, so testing
> upgradesstables for
> # paths from those versions to 4.0 is invalid (and can only fail). There
> isn't currently
> # any difference between the 3.0 and 4.0 sstable format though, but when the
> version is
> # bumped for 4.0, remove the max_version & add a case for testing a 3.0 ->
> 4.0 upgrade
> @since('2.2', max_version='3.X')
> def test_sstableupgrade(self):{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612307#comment-17612307 ] Ekaterina Dimitrova commented on CASSANDRA-17930: - Sounds right to me. Also, it is good to see whether we run them in the right way and same way and number of tests run are correct. As I mentioned in Slack - I am currently looking into some weird differences between Python upgrade tests run in Circle CI and Jenkins for 3.0 and 3.11. We had there more than 10 failures which turned to be just noise and we have some mixed config I am still hunting in CASSANDRA-17912 Probably the easiest for you will be to approach it suite by suite > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicated to configuration and scripts for Circle CI - > [https://github.com/apache/cassandra/tree/trunk/.circleci] > -- This message was sent by Atlassian Jira (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-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612299#comment-17612299 ] Derek Chen-Becker commented on CASSANDRA-17930: --- Splitting into 2 tasks seems reasonable. I'm still coming up to speed on the whole CI system and how it's configured, but it seems like getting CircleCI to run all necessary tests would be the higher priority, right? > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicated to configuration and scripts for Circle CI - > [https://github.com/apache/cassandra/tree/trunk/.circleci] > -- This message was sent by Atlassian Jira (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-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17811:
---
Reviewers: Benjamin Lerer
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(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-17879) It is not possible to autocomplete "WITH" when creating materialized view
[
https://issues.apache.org/jira/browse/CASSANDRA-17879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612215#comment-17612215
]
Stefan Miklosovic commented on CASSANDRA-17879:
---
I am taking care of that. The patch is same for 3.0 as well, fortunately. I ll
build all branches and let you know.
> It is not possible to autocomplete "WITH" when creating materialized view
> -
>
> Key: CASSANDRA-17879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17879
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Brad Schoening
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I noticed that when I type this:
> {code}
> CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1
> IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2)
> {code}
> nothing happens after pressing tab, there should be options shown as for
> table case.
--
This message was sent by Atlassian Jira
(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-17913) Nested selection of reversed collections fails
[
https://issues.apache.org/jira/browse/CASSANDRA-17913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17913:
---
Description:
The following test fails caused by the fact we make reversed a type that wraps
the underline type
{code:java}
@Test
public void testMapsReversed() throws Throwable
{
createTable("CREATE TABLE %s (" +
" k int, " +
" c frozen>, " +
" v int, " +
" PRIMARY KEY(k, c)" +
") WITH CLUSTERING ORDER BY (c DESC)");
execute("SELECT c['testing'] FROM %s");
}
{code}
With the error
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
selection: c is of type frozen> is not a collection
{code}
When you look in a debugger you see that the real type is
ReversedType(MapType(…)), so the current checks fail.
{+}Additional information for newcomers{+}:
* The problem impact element selection as well as range selection that where
introduced in CASSANDRA-7396 as part of 4.0. So the patch will need to be done
for 4.0.
* The checks that needs to be modified is in
{{Selectable.WithElementSelection}} and {{Selectable.WithSliceSelection}}
* The unit tests should be added to {{CollectionsTest}}
was:
The following test fails caused by the fact we make reversed a type that wraps
the underline type
{code:java}
@Test
public void testMapsReversed() throws Throwable
{
createTable("CREATE TABLE %s (" +
" k int, " +
" c frozen>, " +
" v int, " +
" PRIMARY KEY(k, c)" +
") WITH CLUSTERING ORDER BY (c DESC)");
execute("SELECT c['testing'] FROM %s");
}
{code}
With the error
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
selection: c is of type frozen> is not a collection
{code}
When you look in a debugger you see that the real type is
ReversedType(MapType(…)), so the current checks fail.
{+}Additional information for newcomers{+}:
* The problem impact element selection as well as range selection that where
introduced in CASSANDRA-7396 as part of 4.0. So the patch will need to be done
for 4.0.
* The checks that needs to be modified is in
{{Selectable.WithElementSelection}} and {{Selectable.WithSliceSelection}}
> Nested selection of reversed collections fails
> --
>
> Key: CASSANDRA-17913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17913
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, CQL/Semantics, Legacy/Local
> Write-Read Paths
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The following test fails caused by the fact we make reversed a type that
> wraps the underline type
> {code:java}
> @Test
> public void testMapsReversed() throws Throwable
> {
> createTable("CREATE TABLE %s (" +
> " k int, " +
> " c frozen>, " +
> " v int, " +
> " PRIMARY KEY(k, c)" +
> ") WITH CLUSTERING ORDER BY (c DESC)");
> execute("SELECT c['testing'] FROM %s");
> }
> {code}
> With the error
> {code:java}
> org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
> selection: c is of type frozen> is not a collection
> {code}
> When you look in a debugger you see that the real type is
> ReversedType(MapType(…)), so the current checks fail.
> {+}Additional information for newcomers{+}:
> * The problem impact element selection as well as range selection that where
> introduced in CASSANDRA-7396 as part of 4.0. So the patch will need to be
> done for 4.0.
> * The checks that needs to be modified is in
> {{Selectable.WithElementSelection}} and {{Selectable.WithSliceSelection}}
> * The unit tests should be added to {{CollectionsTest}}
--
This message was sent by Atlassian Jira
(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-17913) Nested selection of reversed collections fails
[
https://issues.apache.org/jira/browse/CASSANDRA-17913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17913:
---
Description:
The following test fails caused by the fact we make reversed a type that wraps
the underline type
{code:java}
@Test
public void testMapsReversed() throws Throwable
{
createTable("CREATE TABLE %s (" +
" k int, " +
" c frozen>, " +
" v int, " +
" PRIMARY KEY(k, c)" +
") WITH CLUSTERING ORDER BY (c DESC)");
execute("SELECT c['testing'] FROM %s");
}
{code}
With the error
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
selection: c is of type frozen> is not a collection
{code}
When you look in a debugger you see that the real type is
ReversedType(MapType(…)), so the current checks fail.
{+}Additional information for newcomers{+}:
* The problem impact element selection as well as range selection that where
introduced in CASSANDRA-7396 as part of 4.0. So the patch will need to be done
for 4.0.
* The checks that needs to be modified is in
{{Selectable.WithElementSelection}} and {{Selectable.WithSliceSelection}}
was:
The following test fails caused by the fact we make reversed a type that wraps
the underline type
{code:java}
@Test
public void testMapsReversed() throws Throwable
{
createTable("CREATE TABLE %s (" +
" k int, " +
" c frozen>, " +
" v int, " +
" PRIMARY KEY(k, c)" +
") WITH CLUSTERING ORDER BY (c DESC)");
execute("SELECT c['testing'] FROM %s");
}
{code}
With the error
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
selection: c is of type frozen> is not a collection
{code}
When you look in a debugger you see that the real type is
ReversedType(MapType(…)), so the current checks fail.
{+}Additional information for newcomers{+}:
* The problem impact element selection as well as range selection that where
introduced in 4.0. So the patch will need to be done for 4.0.
*
> Nested selection of reversed collections fails
> --
>
> Key: CASSANDRA-17913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17913
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, CQL/Semantics, Legacy/Local
> Write-Read Paths
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The following test fails caused by the fact we make reversed a type that
> wraps the underline type
> {code:java}
> @Test
> public void testMapsReversed() throws Throwable
> {
> createTable("CREATE TABLE %s (" +
> " k int, " +
> " c frozen>, " +
> " v int, " +
> " PRIMARY KEY(k, c)" +
> ") WITH CLUSTERING ORDER BY (c DESC)");
> execute("SELECT c['testing'] FROM %s");
> }
> {code}
> With the error
> {code:java}
> org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
> selection: c is of type frozen> is not a collection
> {code}
> When you look in a debugger you see that the real type is
> ReversedType(MapType(…)), so the current checks fail.
> {+}Additional information for newcomers{+}:
> * The problem impact element selection as well as range selection that where
> introduced in CASSANDRA-7396 as part of 4.0. So the patch will need to be
> done for 4.0.
> * The checks that needs to be modified is in
> {{Selectable.WithElementSelection}} and {{Selectable.WithSliceSelection}}
--
This message was sent by Atlassian Jira
(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-17913) Nested selection of reversed collections fails
[
https://issues.apache.org/jira/browse/CASSANDRA-17913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17913:
---
Fix Version/s: 4.0.x
4.1.x
(was: 4.x)
> Nested selection of reversed collections fails
> --
>
> Key: CASSANDRA-17913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17913
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, CQL/Semantics, Legacy/Local
> Write-Read Paths
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The following test fails caused by the fact we make reversed a type that
> wraps the underline type
> {code:java}
> @Test
> public void testMapsReversed() throws Throwable
> {
> createTable("CREATE TABLE %s (" +
> " k int, " +
> " c frozen>, " +
> " v int, " +
> " PRIMARY KEY(k, c)" +
> ") WITH CLUSTERING ORDER BY (c DESC)");
> execute("SELECT c['testing'] FROM %s");
> }
> {code}
> With the error
> {code:java}
> org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
> selection: c is of type frozen> is not a collection
> {code}
> When you look in a debugger you see that the real type is
> ReversedType(MapType(…)), so the current checks fail.
> {+}Additional information for newcomers{+}:
> * The problem impact element selection as well as range selection that where
> introduced in 4.0. So the patch will need to be done for 4.0.
> *
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17913) Nested selection of reversed collections fails
[
https://issues.apache.org/jira/browse/CASSANDRA-17913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17913:
---
Description:
The following test fails caused by the fact we make reversed a type that wraps
the underline type
{code:java}
@Test
public void testMapsReversed() throws Throwable
{
createTable("CREATE TABLE %s (" +
" k int, " +
" c frozen>, " +
" v int, " +
" PRIMARY KEY(k, c)" +
") WITH CLUSTERING ORDER BY (c DESC)");
execute("SELECT c['testing'] FROM %s");
}
{code}
With the error
{code:java}
org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
selection: c is of type frozen> is not a collection
{code}
When you look in a debugger you see that the real type is
ReversedType(MapType(…)), so the current checks fail.
{+}Additional information for newcomers{+}:
* The problem impact element selection as well as range selection that where
introduced in 4.0. So the patch will need to be done for 4.0.
*
was:
The following test fails caused by the fact we make reversed a type that wraps
the underline type
{code}
@Test
public void testMapsReversed() throws Throwable
{
createTable("CREATE TABLE %s (" +
" k int, " +
" c frozen>, " +
" v int, " +
" PRIMARY KEY(k, c)" +
") WITH CLUSTERING ORDER BY (c DESC)");
execute("SELECT c['testing'] FROM %s");
}
{code}
With the error
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
selection: c is of type frozen> is not a collection
{code}
When you look in a debugger you see that the real type is
ReversedType(MapType(…)), so the current checks fail.
> Nested selection of reversed collections fails
> --
>
> Key: CASSANDRA-17913
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17913
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, CQL/Semantics, Legacy/Local
> Write-Read Paths
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> The following test fails caused by the fact we make reversed a type that
> wraps the underline type
> {code:java}
> @Test
> public void testMapsReversed() throws Throwable
> {
> createTable("CREATE TABLE %s (" +
> " k int, " +
> " c frozen>, " +
> " v int, " +
> " PRIMARY KEY(k, c)" +
> ") WITH CLUSTERING ORDER BY (c DESC)");
> execute("SELECT c['testing'] FROM %s");
> }
> {code}
> With the error
> {code:java}
> org.apache.cassandra.exceptions.InvalidRequestException: Invalid element
> selection: c is of type frozen> is not a collection
> {code}
> When you look in a debugger you see that the real type is
> ReversedType(MapType(…)), so the current checks fail.
> {+}Additional information for newcomers{+}:
> * The problem impact element selection as well as range selection that where
> introduced in 4.0. So the patch will need to be done for 4.0.
> *
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17918:
---
Description:
The DESCRIBE output of the column names that using reserved keywords are not
quoted for UDTs. The following test reproduces. Reading the code, it looks like
that the such columns names are not quoted in materialized view, UDF and user
defined aggregation.
The impact of the bug is that schema described cannot be imported due to the
usage of reserved keywords as column names.
{code:java}
@Test
public void testUsingReservedInCreateType() throws Throwable
{
String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s (\"token\"
text, \"desc\" text);");
assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
KEYSPACE_PER_TEST + "." + type + " (\n" +
" \"token\" text,\n" +
" \"desc\" text\n" +
");"));
} {code}
+Additional information for newcomers:+
* Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
* The statement implementation is in {{DescribeStatement }}and fetch the
create statement from the different schema element using{{
SchemaElement.toCqlString}}
was:
The DESCRIBE output of the column names that using reserved keywords are not
quoted for UDTs. The following test reproduces. Reading the code, it looks like
that the such columns names are not quoted in materialized view, UDF and user
defined aggregation.
The impact of the bug is that schema described cannot be imported due to the
usage of reserved keywords as column names.
{code:java}
@Test
public void testUsingReservedInCreateType() throws Throwable
{
String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s (\"token\"
text, \"desc\" text);");
assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
KEYSPACE_PER_TEST + "." + type + " (\n" +
" \"token\" text,\n" +
" \"desc\" text\n" +
");"));
} {code}
+Additional information for newcomers:+
* Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
* The statement implementation is in {{DescribeStatement and fetch the create
statement from the different schema element using
{{SchemaElement.toCqlString
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement }}and fetch the
> create statement from the different schema element using{{
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17918:
---
Description:
The DESCRIBE output of the column names that using reserved keywords are not
quoted for UDTs. The following test reproduces. Reading the code, it looks like
that the such columns names are not quoted in materialized view, UDF and user
defined aggregation.
The impact of the bug is that schema described cannot be imported due to the
usage of reserved keywords as column names.
{code:java}
@Test
public void testUsingReservedInCreateType() throws Throwable
{
String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s (\"token\"
text, \"desc\" text);");
assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
KEYSPACE_PER_TEST + "." + type + " (\n" +
" \"token\" text,\n" +
" \"desc\" text\n" +
");"));
} {code}
+Additional information for newcomers:+
* Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
* The statement implementation is in {{DescribeStatement and fetch the create
statement from the different schema element using
{{SchemaElement.toCqlString
was:
The DESCRIBE output of the column names that using reserved keywords are not
quoted for UDTs. The following test reproduces. Reading the code, it looks like
that the such columns names are not quoted in materialized view, UDF and user
defined aggregation.
The impact of the bug is that schema described cannot be imported due to the
usage of reserved keywords as column names.
{code:java}
@Test
public void testUsingReservedInCreateType() throws Throwable
{
String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s (\"token\"
text, \"desc\" text);");
assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
KEYSPACE_PER_TEST + "." + type + " (\n" +
" \"token\" text,\n" +
" \"desc\" text\n" +
");"));
} {code}
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> {{SchemaElement.toCqlString
--
This message was sent by Atlassian Jira
(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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17918:
---
Description:
The DESCRIBE output of the column names that using reserved keywords are not
quoted for UDTs. The following test reproduces. Reading the code, it looks like
that the such columns names are not quoted in materialized view, UDF and user
defined aggregation.
The impact of the bug is that schema described cannot be imported due to the
usage of reserved keywords as column names.
{code:java}
@Test
public void testUsingReservedInCreateType() throws Throwable
{
String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s (\"token\"
text, \"desc\" text);");
assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
KEYSPACE_PER_TEST + "." + type + " (\n" +
" \"token\" text,\n" +
" \"desc\" text\n" +
");"));
} {code}
was:
The DESCRIBE output of the column names that using reserved keywords are not
quoted for UDTs. The following test reproduces. Reading the code, it looks like
that the such columns names are not quoted in materialized view, UDF and user
defined aggregation.
The impact of the bug is that schema described cannot be imported due to the
usage of reserved keywords as column names.
{code:java}
@Test
public void testUsingReservedInCreateType() throws Throwable
{
String input = String.format("CREATE TYPE %s.test_type (\"token\" text,
\"desc\" text);", KEYSPACE);
schemaChange(input);
UntypedResultSet rs = execute(String.format("DESC TYPE %s.test_type",
KEYSPACE));
UntypedResultSet.Row row = rs.one();
String describedCreateStatement = row.getString("create_statement");
Assert.assertEquals("CREATE TYPE cql_test_keyspace.test_type (\n" +
"token text,\n" +
"desc text\n" +
");",
describedCreateStatement);
} {code}
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
