[cassandra-website] branch asf-staging updated (e12ba48d -> 420c9df3)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard e12ba48d generate docs for 2af01b8f new 420c9df3 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 (e12ba48d) \ N -- N -- N refs/heads/asf-staging (420c9df3) 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] [Created] (CASSANDRA-17952) retet
akian uba created CASSANDRA-17952: - Summary: retet Key: CASSANDRA-17952 URL: https://issues.apache.org/jira/browse/CASSANDRA-17952 Project: Cassandra Issue Type: Bug Reporter: akian uba sdfwerew -- This message was sent by Atlassian Jira (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-17952) retet
[ https://issues.apache.org/jira/browse/CASSANDRA-17952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] akian uba updated CASSANDRA-17952: -- Description: sdfwerew [https://www.nena.org/global_engine/download_custom.aspx?fileid=876c6a18-91d2-44c3-af84-673f063ca97f.pdf=cash-app-mone-app-003v1.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=7e0e54e6-ae95-423f-a2e4-827f60cb6c6a.pdf=cash-app-mone-app-003v2.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=0ac3e399-f2f9-478e-85f0-c4aaa95d3fa5.pdf=cash-app-mone-app-003v3.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=d367ff41-c008-4d52-b7bc-e216c561ca72.pdf=cash-app-mone-app-003v4.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=7115c033-7451-44e3-a448-f99428e3b12f.pdf=cash-app-mone-app-003v5.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=51f834a0-e723-4088-b683-43e81f9a754b.pdf=cash-app-money-865v1.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=fd4494cd-5806-4843-a5ce-1ddf1b6b900c.pdf=cash-app-money-865v2.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=dba83f3c-ad0e-4df5-8ebc-0a987508f585.pdf=cash-app-money-865v3.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=c4159752-bee5-48d0-8073-54af361a0f0d.pdf=cash-app-money-865v4.pdf=2=blog=add] [https://www.nena.org/global_engine/download_custom.aspx?fileid=3cb8f029-be4b-4320-b2cd-e533368bfa07.pdf=cash-app-money-865v5.pdf=2=blog=add] was:sdfwerew > retet > - > > Key: CASSANDRA-17952 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17952 > Project: Cassandra > Issue Type: Bug >Reporter: akian uba >Priority: Normal > > sdfwerew > > [https://www.nena.org/global_engine/download_custom.aspx?fileid=876c6a18-91d2-44c3-af84-673f063ca97f.pdf=cash-app-mone-app-003v1.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=7e0e54e6-ae95-423f-a2e4-827f60cb6c6a.pdf=cash-app-mone-app-003v2.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=0ac3e399-f2f9-478e-85f0-c4aaa95d3fa5.pdf=cash-app-mone-app-003v3.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=d367ff41-c008-4d52-b7bc-e216c561ca72.pdf=cash-app-mone-app-003v4.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=7115c033-7451-44e3-a448-f99428e3b12f.pdf=cash-app-mone-app-003v5.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=51f834a0-e723-4088-b683-43e81f9a754b.pdf=cash-app-money-865v1.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=fd4494cd-5806-4843-a5ce-1ddf1b6b900c.pdf=cash-app-money-865v2.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=dba83f3c-ad0e-4df5-8ebc-0a987508f585.pdf=cash-app-money-865v3.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=c4159752-bee5-48d0-8073-54af361a0f0d.pdf=cash-app-money-865v4.pdf=2=blog=add] > [https://www.nena.org/global_engine/download_custom.aspx?fileid=3cb8f029-be4b-4320-b2cd-e533368bfa07.pdf=cash-app-money-865v5.pdf=2=blog=add] -- This message was sent by Atlassian 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 (0cfa3be2 -> e12ba48d)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 0cfa3be2 generate docs for 2af01b8f new e12ba48d 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 (0cfa3be2) \ N -- N -- N refs/heads/asf-staging (e12ba48d) 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] [Updated] (CASSANDRASC-43) Introduce new handler for schema retrieval operations
[ https://issues.apache.org/jira/browse/CASSANDRASC-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-43: -- Change Category: Operability Complexity: Normal Component/s: Rest API Status: Open (was: Triage Needed) > Introduce new handler for schema retrieval operations > - > > Key: CASSANDRASC-43 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-43 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > Schema information is used when performing bulk reads/writes from Cassandra. > The information retrieved is used to map datatypes to other systems such as > Spark. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-43) Introduce new handler for schema retrieval operations
Francisco Guerrero created CASSANDRASC-43: - Summary: Introduce new handler for schema retrieval operations Key: CASSANDRASC-43 URL: https://issues.apache.org/jira/browse/CASSANDRASC-43 Project: Sidecar for Apache Cassandra Issue Type: New Feature Reporter: Francisco Guerrero Assignee: Francisco Guerrero Schema information is used when performing bulk reads/writes from Cassandra. The information retrieved is used to map datatypes to other systems such as Spark. -- This message was sent by Atlassian Jira (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-16304) Consider implementing ClusteringComparator without a lambda
[
https://issues.apache.org/jira/browse/CASSANDRA-16304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613815#comment-17613815
]
Ekaterina Dimitrova commented on CASSANDRA-16304:
-
Just for the record - the latest branch where those can be tested with jdk17 is
- [https://github.com/ekaterinadimitrova2/cassandra/tree/16895-trunk-sept]
It is posted on the main ticket but to make things easier to find adding it
also here.
It was rebased on trunk recently. (it is a rough WIP for testing branch, it
will get cleared in time)
> Consider implementing ClusteringComparator without a lambda
> ---
>
> Key: CASSANDRA-16304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16304
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Adrian Cole
>Priority: Normal
> Fix For: 4.x
>
>
> Using lambdas forces jamm to do things that can easily break. It might be
> safer to implement things like ClusteringComparator directly as classes or as
> an enum
> {noformat}
> Unexpected exception during request
> (org.apache.cassandra.transport.messages.ErrorMessage)
> java.lang.UnsupportedOperationException: can't get field offset on a hidden
> class: private final org.apache.cassandra.db.ClusteringComparator
> org.apache.cassandra.db.ClusteringComparator$$Lambda$165/0x00010028ab60.arg$1
> at jdk.unsupported/sun.misc.Unsafe.objectFieldOffset(Unknown Source)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfInstanceWithUnsafe(MemoryLayoutSpecification.java:108)
> at
> org.github.jamm.MemoryLayoutSpecification.sizeOfWithUnsafe(MemoryLayoutSpecification.java:89)
> at org.github.jamm.MemoryMeter.measure(MemoryMeter.java:217)
> at org.github.jamm.MemoryMeter.measureDeep(MemoryMeter.java:259)
> at
> org.apache.cassandra.utils.ObjectSizes.measureDeep(ObjectSizes.java:155)
> at
> org.apache.cassandra.cql3.QueryProcessor.storePreparedStatement(QueryProcessor.java:454)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:424)
> at
> org.apache.cassandra.cql3.QueryProcessor.prepare(QueryProcessor.java:408)
> at
> org.apache.cassandra.transport.messages.PrepareMessage.execute(PrepareMessage.java:114)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:253)
> at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:725)
> at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:630)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Unknown Source)
> {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
[cassandra-website] branch asf-staging updated (39ba107b -> 0cfa3be2)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 39ba107b generate docs for 2af01b8f new 0cfa3be2 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 (39ba107b) \ N -- N -- N refs/heads/asf-staging (0cfa3be2) 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] [Commented] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613808#comment-17613808 ] Ekaterina Dimitrova commented on CASSANDRA-16895: - Short update - there are a few linked tickets plus I was doing a revision of opens/exports and what internals we access through setAccessible at the moment. Also, gathered some more information around some of the dependency updates, more tickets will follow. Jamm work will be handled probably by another person I am in contact with. More to follow. > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > This ticket is intended to group all issues found to support Java 17 in the > future. > Upgrade steps: > * [Dependencies > |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to > be updated (not all but at least those that require an update in order to > work with Java 17) > * More encapsulated JDK internal APIs. Some of the issues might be solved > with the dependencies updates > * Currently trunk compiles if we remove the Nashorn dependency (ant script > tag, used for the test environment; UDFs) . The oracle recommendation to use > Nashorn-core won't work for the project as it is under GPL 2.0. Most probably > we will opt in for graal-sdk licensed under UPL > * All tests to be cleaned > * CI environment to be setup -- This message was sent by Atlassian 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 (e7b262d9 -> 39ba107b)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard e7b262d9 generate docs for 2af01b8f new 39ba107b 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 (e7b262d9) \ N -- N -- N refs/heads/asf-staging (39ba107b) 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] [Updated] (CASSANDRA-17951) Update AssertJ
[ https://issues.apache.org/jira/browse/CASSANDRA-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17951: Description: >From the changelog of AssertJ >[here|https://assertj.github.io/doc/#assertj-core-3-23-1-release-notes] it >seems JDK17 is tested and relevant issues fixed as per 3.23.1 and we are on >3.15.0 This ticket should accommodate upgrade to 3.23.1 for trunk was: >From the changelog of AssertJ [here|] it seems JDK17 is tested and relevant >issues fixed as per 3.23.1 and we are on 3.15.0 This ticket should accommodate upgrade to 3.23.1 for trunk > Update AssertJ > -- > > Key: CASSANDRA-17951 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17951 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > From the changelog of AssertJ > [here|https://assertj.github.io/doc/#assertj-core-3-23-1-release-notes] it > seems JDK17 is tested and relevant issues fixed as per 3.23.1 and we are on > 3.15.0 > This ticket should accommodate upgrade to 3.23.1 for trunk > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17951) Update AssertJ
[ https://issues.apache.org/jira/browse/CASSANDRA-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17951: Fix Version/s: 4.x > Update AssertJ > -- > > Key: CASSANDRA-17951 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17951 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > From the changelog of AssertJ [here|] it seems JDK17 is tested and relevant > issues fixed as per 3.23.1 and we are on 3.15.0 > This ticket should accommodate upgrade to 3.23.1 for trunk > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17951) Update AssertJ
Ekaterina Dimitrova created CASSANDRA-17951: --- Summary: Update AssertJ Key: CASSANDRA-17951 URL: https://issues.apache.org/jira/browse/CASSANDRA-17951 Project: Cassandra Issue Type: Task Reporter: Ekaterina Dimitrova >From the changelog of AssertJ [here|] it seems JDK17 is tested and relevant >issues fixed as per 3.23.1 and we are on 3.15.0 This ticket should accommodate upgrade to 3.23.1 for trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17951) Update AssertJ
[ https://issues.apache.org/jira/browse/CASSANDRA-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17951: Change Category: Operability Complexity: Normal Component/s: Dependencies Assignee: Ekaterina Dimitrova Status: Open (was: Triage Needed) > Update AssertJ > -- > > Key: CASSANDRA-17951 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17951 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > From the changelog of AssertJ [here|] it seems JDK17 is tested and relevant > issues fixed as per 3.23.1 and we are on 3.15.0 > This ticket should accommodate upgrade to 3.23.1 for trunk > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17562) Add additional new JMX methods for the old Config migrated to the new types
[ https://issues.apache.org/jira/browse/CASSANDRA-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17562: --- Assignee: (was: Ekaterina Dimitrova) > Add additional new JMX methods for the old Config migrated to the new types > --- > > Key: CASSANDRA-17562 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17562 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In CASSANDRA-15234 we migrated config parameters to new types. The old JMX > methods which use primitives are still working as expected. We need to add > also new JMX methods for the new types, the getters/setters will get/set > String until write mode is added to the Settings virtual table. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17532: --- Assignee: (was: Ekaterina Dimitrova) > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- This message was sent by Atlassian Jira (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-17551) Allow 0 to be used in collection_size guardrails in order to prohibit collections
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17551: Resolution: Won't Do Status: Resolved (was: Open) > Allow 0 to be used in collection_size guardrails in order to prohibit > collections > - > > Key: CASSANDRA-17551 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17551 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Allow 0 to be used in collection_size guardrails in order to prohibit > collections -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17515) Fix setters for native_transport_max_concurrent_requests_in_bytes and native_transport_max_concurrent_requests_in_bytes_per_ip
[ https://issues.apache.org/jira/browse/CASSANDRA-17515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17515: --- Assignee: (was: Ekaterina Dimitrova) > Fix setters for native_transport_max_concurrent_requests_in_bytes and > native_transport_max_concurrent_requests_in_bytes_per_ip > --- > > Key: CASSANDRA-17515 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17515 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > While working on CASSANDRA-17341 we noticed that while > native_transport_max_concurrent_requests_in_bytes and > native_transport_max_concurrent_requests_in_bytes_per_ip are checked for -1 > during startup and have default value, this is not the case in their setters. > We fixed this for trunk but those properties exist also in previous versions. > We need to check those setters and probably to back port similar fix. > CC [~maedhroz] , [~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-17551) Allow 0 to be used in collection_size guardrails in order to prohibit collections
[ https://issues.apache.org/jira/browse/CASSANDRA-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613771#comment-17613771 ] Ekaterina Dimitrova commented on CASSANDRA-17551: - I do not think we will work on this really any time soon. Closing for now. We can reopen/open new one in case we get back to this idea. > Allow 0 to be used in collection_size guardrails in order to prohibit > collections > - > > Key: CASSANDRA-17551 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17551 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Allow 0 to be used in collection_size guardrails in order to prohibit > collections -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17798) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
[
https://issues.apache.org/jira/browse/CASSANDRA-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova reassigned CASSANDRA-17798:
---
Assignee: (was: Ekaterina Dimitrova)
> Flaky org.apache.cassandra.tools TopPartitionsTest
> testServiceTopPartitionsSingleTable
> --
>
> Key: CASSANDRA-17798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17798
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> h3.
> {code:java}
> Error Message
> If this failed you probably have to raise the beginLocalSampling duration
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: If this failed you probably have to
> raise the beginLocalSampling duration expected:<1> but was:<0> at
> org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable(TopPartitionsTest.java:83)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-02 01:49:49,333 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main]
> 2022-08-02 01:49:49,339 YamlConfigurationLoader.java:124 - Loading settings
> from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO
> [main] 2022-08-02 01:49:49,642 Config.java:1167 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null; allow_extra_insecure
> ...[truncated 50809 chars]... lizing counter cache with capacity of 2 MiBs
> INFO [MemtableFlushWriter:1] 2022-08-02 01:49:53,519 CacheService.java:163 -
> Scheduling counter cache save to every 7200 seconds (going to save all keys).
> DEBUG [MemtableFlushWriter:1] 2022-08-02 01:49:53,575
> ColumnFamilyStore.java:1330 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/nb-1-big-Data.db')]
> (1 sstables, 4.915KiB), biggest 4.915KiB, smallest 4.915KiB
> {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-17798) Flaky org.apache.cassandra.tools TopPartitionsTest testServiceTopPartitionsSingleTable
[
https://issues.apache.org/jira/browse/CASSANDRA-17798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613770#comment-17613770
]
Ekaterina Dimitrova commented on CASSANDRA-17798:
-
I am not sure I will have time for this one any time soon so I am unassigning
it in case someone gets to it before me.
> Flaky org.apache.cassandra.tools TopPartitionsTest
> testServiceTopPartitionsSingleTable
> --
>
> Key: CASSANDRA-17798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17798
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> h3.
> {code:java}
> Error Message
> If this failed you probably have to raise the beginLocalSampling duration
> expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: If this failed you probably have to
> raise the beginLocalSampling duration expected:<1> but was:<0> at
> org.apache.cassandra.tools.TopPartitionsTest.testServiceTopPartitionsSingleTable(TopPartitionsTest.java:83)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-08-02 01:49:49,333 YamlConfigurationLoader.java:104 -
> Configuration location:
> file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml DEBUG [main]
> 2022-08-02 01:49:49,339 YamlConfigurationLoader.java:124 - Loading settings
> from file:home/cassandra/cassandra/build/test/cassandra.cdc.yaml INFO
> [main] 2022-08-02 01:49:49,642 Config.java:1167 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null; allow_extra_insecure
> ...[truncated 50809 chars]... lizing counter cache with capacity of 2 MiBs
> INFO [MemtableFlushWriter:1] 2022-08-02 01:49:53,519 CacheService.java:163 -
> Scheduling counter cache save to every 7200 seconds (going to save all keys).
> DEBUG [MemtableFlushWriter:1] 2022-08-02 01:49:53,575
> ColumnFamilyStore.java:1330 - Flushed to
> [BigTableReader(path='/home/cassandra/cassandra/build/test/cassandra/data/system/IndexInfo-9f5c6374d48532299a0a5094af9ad1e3/nb-1-big-Data.db')]
> (1 sstables, 4.915KiB), biggest 4.915KiB, smallest 4.915KiB
> {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-17885) Add solution for CASSANDRA-17581 to older branches for tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613769#comment-17613769 ] Ekaterina Dimitrova commented on CASSANDRA-17885: - Thanks, I will be off for some time. As long as all branches pass on both CIs with the new image from CASSANDRA-17854 I think I am +1 on this patch. I still think it might have been easier to make a ccm patch but I understand it hides its own risks and considerations and you are already at the finish line with this one. > Add solution for CASSANDRA-17581 to older branches for tests > > > Key: CASSANDRA-17885 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17885 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x > > > Some of our tests use old branches for the purposes of testing upgrades and > behavior in mixed versions, but those lacking CASSANDRA-17581 will fail on > nodetool with a modern JDK. We can port this fix to those branches and > adjust the tests to use the newest version of them to solve this going > forward. -- This message was sent by Atlassian Jira (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-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613768#comment-17613768 ] Ekaterina Dimitrova commented on CASSANDRA-17854: - Still blocked on CASSANDRA-17885. Moving to open as I will be off for a bit and I will get back to it when I am back later this month. > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17671) Run utests_system_keyspace_directory with Java 11 in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-17671: --- Assignee: (was: Ekaterina Dimitrova) > Run utests_system_keyspace_directory with Java 11 in CircleCI > - > > Key: CASSANDRA-17671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17671 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > Currently we run those tests only with Java 8, I have to dig into it further > but it seems that there is no specific reason not to run those with Java 11 > too. -- This message was sent by Atlassian Jira (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=17613760#comment-17613760
]
Ekaterina Dimitrova commented on CASSANDRA-17930:
-
I just linked CASSANDRA-17671 which I just found in my list, opened long ago
but never got to it. I will unassign it as I won't be able to work on it soon I
think if you or anyone else have cycles to deal with it. With that said, I will
be off until 18th October, I will be happy to get back to these problems when I
am back.
{quote}What I mean by a long-term driven by a single config is it would be
ideal to have a (simple) way to define a test in one place, and be able to
generate the configurations for CircleCI, Jenkins, and whatever other CI system
we decide to use from that canonical source. I'm not saying that this ticket is
where this happens, I'm just saying a system where you rely on good intentions
to ensure parity is statistically unlikely to maintain that parity over time.
{quote}
Happy to see a written proposal if you are willing to work on such an
implementation after we fill the short-term goals here. I am sure there are
areas of improvement and that every setup evolves in time but also needs
someone with time to be able to sit and work hard on it. So with that said
happy to see you are interested in this area.
{quote} If changing the name of a test doesn't otherwise change or break its
behavior, do you have an objection?
{quote}
I personally do not have any objections to bring things to aligned names where
it makes sense. My request was just such an improvement to be in a separate
ticket. Thanks for looking into that.
> 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-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613758#comment-17613758
]
Andy Tolbert commented on CASSANDRA-17945:
--
Awesome, thank you so much [~aweisberg] for reviewing and getting this
committed and [~brandon.williams] for the +1 as well!
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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() +
[jira] [Updated] (CASSANDRA-17671) Run utests_system_keyspace_directory with Java 11 in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17671: Issue Type: Task (was: Improvement) > Run utests_system_keyspace_directory with Java 11 in CircleCI > - > > Key: CASSANDRA-17671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17671 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Currently we run those tests only with Java 8, I have to dig into it further > but it seems that there is no specific reason not to run those with Java 11 > too. -- This message was sent by Atlassian 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 (7d4a7d69 -> e7b262d9)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 7d4a7d69 generate docs for 2af01b8f new e7b262d9 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 (7d4a7d69) \ N -- N -- N refs/heads/asf-staging (e7b262d9) 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] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-17945:
---
Status: Ready to Commit (was: Review In Progress)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
>
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-17945:
---
Status: Review In Progress (was: Patch Available)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
>
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-17945:
---
Status: Patch Available (was: In Progress)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
>
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-17945:
---
Source Control Link:
https://github.com/apache/cassandra/commit/3bdd2caa22a0413929188536b41d8117177574fa
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
[jira] [Commented] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613752#comment-17613752
]
Ariel Weisberg commented on CASSANDRA-17945:
Committed as
[3bdd2caa22a0413929188536b41d8117177574fa|https://github.com/apache/cassandra/commit/3bdd2caa22a0413929188536b41d8117177574fa].
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
[jira] [Comment Edited] (CASSANDRA-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613745#comment-17613745 ] Stefan Miklosovic edited comment on CASSANDRA-17948 at 10/6/22 6:30 PM: btw, in practice, ThresholdFilter would be set at least to WARN, I do not think there is a lot of added value to go through INFO logs, why would you? There is other telemetry for that, diagnostic events, jmx metrics ... but WARN or ERROR would be nice to see for sure. So there will not be a lot of WARNs or ERRORs in runtime, a magnitude less than INFO. It would take quite a buggy node to fill that buffer with WARN or ERROR only. More to it, from CASSANDRA-16806 it is possible to TRUNCATE / DELETE on vtables. So if you find the buffer full or your are not interested in that anymore you can just truncate and clear that buffer completely. was (Author: smiklosovic): btw, in practice, ThresholdFilter would be set at least to WARN, I do not think there is a lot of added value to go through INFO logs, why would you? There is other telemetry for that, diagnostic events, jmx metrics ... but WARN or ERROR would be nice to see for sure. So there will not be a lot of WARNs or ERRORs in runtime, a magnitude less than INFO. It would take quite a buggy node to fill that buffer with WARN or ERROR only. > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian Jira (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-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613745#comment-17613745 ] Stefan Miklosovic commented on CASSANDRA-17948: --- btw, in practice, ThresholdFilter would be set at least to WARN, I do not think there is a lot of added value to go through INFO logs, why would you? There is other telemetry for that, diagnostic events, jmx metrics ... but WARN or ERROR would be nice to see for sure. So there will not be a lot of WARNs or ERRORs in runtime, a magnitude less than INFO. It would take quite a buggy node to fill that buffer with WARN or ERROR only. > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian 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 cassandra-4.0 updated (0c4daa1ddc -> 3bdd2caa22)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0c4daa1ddc Fix up CHANGES.txt chaos add 3bdd2caa22 Fix StorageService.getNativeaddress handling of IPv6 addresses No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/service/StorageService.java | 27 +++--- .../service/StorageServiceServerTest.java | 22 ++ 3 files changed, 47 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (fb4974d455 -> 9524c22990)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from fb4974d455 Merge branch 'cassandra-4.0' into cassandra-4.1 add 3bdd2caa22 Fix StorageService.getNativeaddress handling of IPv6 addresses add 9524c22990 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/service/StorageService.java | 27 +++--- .../service/StorageServiceServerTest.java | 22 ++ 3 files changed, 47 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613741#comment-17613741 ] Stefan Miklosovic commented on CASSANDRA-17948: --- yes, that what Brandon said, plus files on the disk are going to be rolled up by whatever policy you have, so, people would get kilometers-long logs ... until they don't, because it will start to write to new file from the start when the original file is too big. What happens when we try to read in the middle of slf4j gzipping that file? > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian 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 (472dc30faa -> d62d845c7d)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 472dc30faa Merge branch 'cassandra-4.1' into trunk new 3bdd2caa22 Fix StorageService.getNativeaddress handling of IPv6 addresses new 9524c22990 Merge branch 'cassandra-4.0' into cassandra-4.1 new d62d845c7d Merge branch 'cassandra-4.1' into trunk The 3 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: CHANGES.txt| 1 + .../apache/cassandra/service/StorageService.java | 27 +++--- .../service/StorageServiceServerTest.java | 22 ++ 3 files changed, 47 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 03/03: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d62d845c7d86b6ca5ea4d63042123d1b3802ae5e Merge: 472dc30faa 9524c22990 Author: Ariel Weisberg AuthorDate: Thu Oct 6 14:11:50 2022 -0400 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 1 + .../apache/cassandra/service/StorageService.java | 27 +++--- .../service/StorageServiceServerTest.java | 22 ++ 3 files changed, 47 insertions(+), 3 deletions(-) diff --cc CHANGES.txt index 3c4c1785d2,6a04c99148..c418c48ba9 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -88,6 -37,6 +88,7 @@@ Merged from 4.1 * Revert removal of withBufferSizeInMB(int size) in CQLSSTableWriter.Builder class and deprecate it in favor of withBufferSizeInMiB(int size) (CASSANDRA-17675) * Remove expired snapshots of dropped tables after restart (CASSANDRA-17619) Merged from 4.0: ++ * Fix StorageService.getNativeaddress handling of IPv6 addresses (CASSANDRA-17945) * Mitigate direct buffer memory OOM on replacements (CASSANDRA-17895) * Fix repair failure on assertion if two peers have overlapping mismatching ranges (CASSANDRA-17900) * Better handle null state in Gossip schema migration to avoid NPE (CASSANDRA-17864) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/03: Fix StorageService.getNativeaddress handling of IPv6 addresses
This is an automated email from the ASF dual-hosted git repository.
aweisberg pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 3bdd2caa22a0413929188536b41d8117177574fa
Author: Andy Tolbert <6889771+tolber...@users.noreply.github.com>
AuthorDate: Thu Oct 6 14:04:38 2022 -0400
Fix StorageService.getNativeaddress handling of IPv6 addresses
StorageService.getNativeaddress does not currently correctly handle
IPv6 addresses correctly when NATIVE_ADDRESS_AND_PORT are not present in
that it simply concatenates the IP address with the default native port,
e.g.:
0:0:0:0:0:0:5a:3:9042
This does not parse into an InetSocketAddress as the address and port
can't be disambiguated.
Such a case would usually be present when there are 3.x nodes present in a
cluster with 4.0 nodes.
Change updates RPC_ADDRESS and else case to create InetAddressAndPort
instances
with DatabaseDescriptor.getNativeTransportPort and returns the
getHostAddress(withPort) which properly bracket encodes the address,
e.g.:
[0:0:0:0:0:0:5a:3]:9042
which can be parsed as an InetSocketAddress.
patch by Andy Tolbert; reviewed by Ariel Weisberg, Brandon Williams for
CASSANDRA-17945
---
CHANGES.txt| 1 +
.../apache/cassandra/service/StorageService.java | 27 +++---
.../service/StorageServiceServerTest.java | 22 ++
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 15bc6413ad..d48edb9a4f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0.7
+ * Fix StorageService.getNativeaddress handling of IPv6 addresses
(CASSANDRA-17945)
* Mitigate direct buffer memory OOM on replacements (CASSANDRA-17895)
* Fix repair failure on assertion if two peers have overlapping mismatching
ranges (CASSANDRA-17900)
* Better handle null state in Gossip schema migration to avoid NPE
(CASSANDRA-17864)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 7e70e4ce20..b70347a301 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -1975,10 +1975,31 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
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();
+{
+ final String ipAddress;
+ // If RPC_ADDRESS present in gossip for this endpoint use it.
This is expected for 3.x nodes.
+ if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
!= null)
+ {
+ ipAddress =
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value;
+ }
+ else
+ {
+ // otherwise just use the IP of the endpoint itself.
+ ipAddress = endpoint.getHostAddress(false);
+ }
+
+ // include the configured native_transport_port.
+ try
+ {
+ InetAddressAndPort address =
InetAddressAndPort.getByNameOverrideDefaults(ipAddress,
DatabaseDescriptor.getNativeTransportPort());
+ return address.getHostAddress(withPort);
+ }
+ catch (UnknownHostException e)
+ {
+ throw new RuntimeException(e);
+ }
+ }
}
public Map, List> getRangeToRpcaddressMap(String
keyspace)
diff --git
a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
index b5ddd35514..60bed4c64d 100644
--- a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
+++ b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
@@ -641,6 +641,28 @@ public class StorageServiceServerTest
assertEquals("127.0.0.3:666",
StorageService.instance.getNativeaddress(internalAddress, true));
}
+@Test
+public void testGetNativeAddressIPV6() throws Exception
+{
+// Ensure IPv6 addresses are properly bracketed in RFC2732
(https://datatracker.ietf.org/doc/html/rfc2732) format when including ports.
+// See https://issues.apache.org/jira/browse/CASSANDRA-17945 for
[cassandra] 02/03: Merge branch 'cassandra-4.0' into cassandra-4.1
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9524c22990de62d42c7909ff4e2635e238e7ee48 Merge: fb4974d455 3bdd2caa22 Author: Ariel Weisberg AuthorDate: Thu Oct 6 14:11:00 2022 -0400 Merge branch 'cassandra-4.0' into cassandra-4.1 CHANGES.txt| 1 + .../apache/cassandra/service/StorageService.java | 27 +++--- .../service/StorageServiceServerTest.java | 22 ++ 3 files changed, 47 insertions(+), 3 deletions(-) diff --cc CHANGES.txt index 41a625cec9,d48edb9a4f..6a04c99148 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,41 -1,5 +1,42 @@@ -4.0.7 +4.1-beta2 + * Allow pre-V5 global limit on bytes in flight to revert to zero asynchronously in RateLimitingTest (CASSANDRA-17927) +Merged from 4.0: + * Fix StorageService.getNativeaddress handling of IPv6 addresses (CASSANDRA-17945) +Merged from 3.11: + * Make LongBufferPoolTest insensitive to timing (CASSANDRA-16681) +Merged from 3.0: + * Fix auto-completing "WITH" when creating a materialized view (CASSANDRA-17879) + +4.1-beta1 + * We should not emit deprecation warning on startup for `key_cache_save_period`, `row_cache_save_period`, `counter_cache_save_period` (CASSANDRA-17904) + * upsert with adder support is not consistent with numbers and strings in LWT (CASSANDRA-17857) + * Fix race and return after failing connections (CASSANDRA-17618) + * Speculative execution threshold unit mismatch (CASSANDRA-17877) + * Fix BulkLoader to load entireSSTableThrottle and entireSSTableInterDcThrottle (CASSANDRA-17677) + * Fix a race condition where a keyspace can be oopened while it is being removed (CASSANDRA-17658) + * DatabaseDescriptor will set the default failure detector during client initialization (CASSANDRA-17782) + * Avoid initializing schema via SystemKeyspace.getPreferredIP() with the BulkLoader tool (CASSANDRA-17740) + * Improve JMX methods signatures, fix JMX and config backward compatibility (CASSANDRA-17725) + * Fix sstable_preemptive_open_interval disabled value. sstable_preemptive_open_interval = null backward compatible with + sstable_preemptive_open_interval_in_mb = -1 (CASSANDRA-17737) + * Remove usages of Path#toFile() in the snapshot apparatus (CASSANDRA-17769) + * Fix Settings Virtual Table to update paxos_variant after startup and rename enable_uuid_sstable_identifiers to + uuid_sstable_identifiers_enabled as per our config naming conventions (CASSANDRA-17738) + * index_summary_resize_interval_in_minutes = -1 is equivalent to index_summary_resize_interval being set to null or + disabled. JMX MBean IndexSummaryManager, setResizeIntervalInMinutes method still takes resizeIntervalInMinutes = -1 for disabled (CASSANDRA-17735) + * min_tracked_partition_size_bytes parameter from 4.1 alpha1 was renamed to min_tracked_partition_size (CASSANDRA-17733) + * Remove commons-lang dependency during build runtime (CASSANDRA-17724) + * Relax synchronization on StreamSession#onError() to avoid deadlock (CASSANDRA-17706) + * Fix AbstractCell#toString throws MarshalException for cell in collection (CASSANDRA-17695) + * Add new vtable output option to compactionstats (CASSANDRA-17683) + * Fix commitLogUpperBound initialization in AbstractMemtableWithCommitlog (CASSANDRA-17587) + * Fix widening to long in getBatchSizeFailThreshold (CASSANDRA-17650) + * Fix widening from mebibytes to bytes in IntMebibytesBound (CASSANDRA-17716) + * Revert breaking change in nodetool clientstats and expose cient options through nodetool clientstats --client-options. (CASSANDRA-17715) + * Fix missed nowInSec values in QueryProcessor (CASSANDRA-17458) + * Revert removal of withBufferSizeInMB(int size) in CQLSSTableWriter.Builder class and deprecate it in favor of withBufferSizeInMiB(int size) (CASSANDRA-17675) + * Remove expired snapshots of dropped tables after restart (CASSANDRA-17619) +Merged from 4.0: * Mitigate direct buffer memory OOM on replacements (CASSANDRA-17895) * Fix repair failure on assertion if two peers have overlapping mismatching ranges (CASSANDRA-17900) * Better handle null state in Gossip schema migration to avoid NPE (CASSANDRA-17864) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-17945-trunk-guest created (now 833de7bb94)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch cassandra-17945-trunk-guest in repository https://gitbox.apache.org/repos/asf/cassandra.git at 833de7bb94 Update StorageService.getNativeaddress to handle IPv6 addresses This branch includes the following new commits: new 833de7bb94 Update StorageService.getNativeaddress to handle IPv6 addresses 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Update StorageService.getNativeaddress to handle IPv6 addresses
This is an automated email from the ASF dual-hosted git repository.
aweisberg pushed a commit to branch cassandra-17945-trunk-guest
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 833de7bb9460c1de2e678cd1bddd315ef8b40cfb
Author: Andy Tolbert <6889771+tolber...@users.noreply.github.com>
AuthorDate: Tue Oct 4 12:02:26 2022 -0500
Update StorageService.getNativeaddress to handle IPv6 addresses
StorageService.getNativeaddress does not currently correctly handle
IPv6 addresses correctly when NATIVE_ADDRESS_AND_PORT are not present in
that it simply concatenates the IP address with the default native port,
e.g.:
0:0:0:0:0:0:5a:3:9042
This does not parse into an InetSocketAddress as the address and port
can't be disambiguated.
Such a case would usually be present when there are 3.x nodes present in a
cluster with 4.0 nodes.
Change updates RPC_ADDRESS and else case to create InetAddressAndPort
instances
with DatabaseDescriptor.getNativeTransportPort and returns the
getHostAddress(withPort) which properly bracket encodes the address,
e.g.:
[0:0:0:0:0:0:5a:3]:9042
which can be parsed as an InetSocketAddress.
---
.../apache/cassandra/service/StorageService.java | 27 +++---
.../service/StorageServiceServerTest.java | 22 ++
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index a8b27bfc22..965d19509b 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2158,10 +2158,31 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
throw new RuntimeException(e);
}
}
-else if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
== null)
-return endpoint.getAddress().getHostAddress() + ":" +
DatabaseDescriptor.getNativeTransportPort();
else
-return
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value
+ ":" + DatabaseDescriptor.getNativeTransportPort();
+{
+ final String ipAddress;
+ // If RPC_ADDRESS present in gossip for this endpoint use it.
This is expected for 3.x nodes.
+ if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
!= null)
+ {
+ ipAddress =
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value;
+ }
+ else
+ {
+ // otherwise just use the IP of the endpoint itself.
+ ipAddress = endpoint.getHostAddress(false);
+ }
+
+ // include the configured native_transport_port.
+ try
+ {
+ InetAddressAndPort address =
InetAddressAndPort.getByNameOverrideDefaults(ipAddress,
DatabaseDescriptor.getNativeTransportPort());
+ return address.getHostAddress(withPort);
+ }
+ catch (UnknownHostException e)
+ {
+ throw new RuntimeException(e);
+ }
+ }
}
public Map, List> getRangeToRpcaddressMap(String
keyspace)
diff --git
a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
index c8739ae1bc..119b8104d4 100644
--- a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
+++ b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
@@ -572,6 +572,28 @@ public class StorageServiceServerTest
assertEquals("127.0.0.3:666",
StorageService.instance.getNativeaddress(internalAddress, true));
}
+@Test
+public void testGetNativeAddressIPV6() throws Exception
+{
+// Ensure IPv6 addresses are properly bracketed in RFC2732
(https://datatracker.ietf.org/doc/html/rfc2732) format when including ports.
+// See https://issues.apache.org/jira/browse/CASSANDRA-17945 for more
context.
+String internalAddressIPV6String = "[0:0:0:0:0:0:0:3]:666";
+InetAddressAndPort internalAddressIPV6 =
InetAddressAndPort.getByName(internalAddressIPV6String);
+Gossiper.instance.addSavedEndpoint(internalAddressIPV6);
+
+//Default to using the provided address with the configured port
+assertEquals("[0:0:0:0:0:0:0:3]:" +
DatabaseDescriptor.getNativeTransportPort(),
StorageService.instance.getNativeaddress(internalAddressIPV6, true));
+
+VersionedValue.VersionedValueFactory valueFactory = new
[cassandra] 01/01: Update StorageService.getNativeaddress to handle IPv6 addresses
This is an automated email from the ASF dual-hosted git repository.
aweisberg pushed a commit to branch cassandra-17945-4.1-guest
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 57c8e686673d15f84183062df6e411a6191f6b26
Author: Andy Tolbert <6889771+tolber...@users.noreply.github.com>
AuthorDate: Tue Oct 4 12:02:26 2022 -0500
Update StorageService.getNativeaddress to handle IPv6 addresses
StorageService.getNativeaddress does not currently correctly handle
IPv6 addresses correctly when NATIVE_ADDRESS_AND_PORT are not present in
that it simply concatenates the IP address with the default native port,
e.g.:
0:0:0:0:0:0:5a:3:9042
This does not parse into an InetSocketAddress as the address and port
can't be disambiguated.
Such a case would usually be present when there are 3.x nodes present in a
cluster with 4.0 nodes.
Change updates RPC_ADDRESS and else case to create InetAddressAndPort
instances
with DatabaseDescriptor.getNativeTransportPort and returns the
getHostAddress(withPort) which properly bracket encodes the address,
e.g.:
[0:0:0:0:0:0:5a:3]:9042
which can be parsed as an InetSocketAddress.
---
.../apache/cassandra/service/StorageService.java | 27 +++---
.../service/StorageServiceServerTest.java | 22 ++
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 0d0ede5ab7..b39c049c88 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -2136,10 +2136,31 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
throw new RuntimeException(e);
}
}
-else if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
== null)
-return endpoint.getAddress().getHostAddress() + ":" +
DatabaseDescriptor.getNativeTransportPort();
else
-return
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value
+ ":" + DatabaseDescriptor.getNativeTransportPort();
+{
+ final String ipAddress;
+ // If RPC_ADDRESS present in gossip for this endpoint use it.
This is expected for 3.x nodes.
+ if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
!= null)
+ {
+ ipAddress =
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value;
+ }
+ else
+ {
+ // otherwise just use the IP of the endpoint itself.
+ ipAddress = endpoint.getHostAddress(false);
+ }
+
+ // include the configured native_transport_port.
+ try
+ {
+ InetAddressAndPort address =
InetAddressAndPort.getByNameOverrideDefaults(ipAddress,
DatabaseDescriptor.getNativeTransportPort());
+ return address.getHostAddress(withPort);
+ }
+ catch (UnknownHostException e)
+ {
+ throw new RuntimeException(e);
+ }
+ }
}
public Map, List> getRangeToRpcaddressMap(String
keyspace)
diff --git
a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
index c8739ae1bc..119b8104d4 100644
--- a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
+++ b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
@@ -572,6 +572,28 @@ public class StorageServiceServerTest
assertEquals("127.0.0.3:666",
StorageService.instance.getNativeaddress(internalAddress, true));
}
+@Test
+public void testGetNativeAddressIPV6() throws Exception
+{
+// Ensure IPv6 addresses are properly bracketed in RFC2732
(https://datatracker.ietf.org/doc/html/rfc2732) format when including ports.
+// See https://issues.apache.org/jira/browse/CASSANDRA-17945 for more
context.
+String internalAddressIPV6String = "[0:0:0:0:0:0:0:3]:666";
+InetAddressAndPort internalAddressIPV6 =
InetAddressAndPort.getByName(internalAddressIPV6String);
+Gossiper.instance.addSavedEndpoint(internalAddressIPV6);
+
+//Default to using the provided address with the configured port
+assertEquals("[0:0:0:0:0:0:0:3]:" +
DatabaseDescriptor.getNativeTransportPort(),
StorageService.instance.getNativeaddress(internalAddressIPV6, true));
+
+VersionedValue.VersionedValueFactory valueFactory = new
[cassandra] branch cassandra-17945-4.1-guest created (now 57c8e68667)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch cassandra-17945-4.1-guest in repository https://gitbox.apache.org/repos/asf/cassandra.git at 57c8e68667 Update StorageService.getNativeaddress to handle IPv6 addresses This branch includes the following new commits: new 57c8e68667 Update StorageService.getNativeaddress to handle IPv6 addresses 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Update StorageService.getNativeaddress to handle IPv6 addresses
This is an automated email from the ASF dual-hosted git repository.
aweisberg pushed a commit to branch cassandra-17945-4.0-guest
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit c50ab514114415973cb6edc7a5c7e914528e812f
Author: Andy Tolbert <6889771+tolber...@users.noreply.github.com>
AuthorDate: Tue Oct 4 12:02:26 2022 -0500
Update StorageService.getNativeaddress to handle IPv6 addresses
StorageService.getNativeaddress does not currently correctly handle
IPv6 addresses correctly when NATIVE_ADDRESS_AND_PORT are not present in
that it simply concatenates the IP address with the default native port,
e.g.:
0:0:0:0:0:0:5a:3:9042
This does not parse into an InetSocketAddress as the address and port
can't be disambiguated.
Such a case would usually be present when there are 3.x nodes present in a
cluster with 4.0 nodes.
Change updates RPC_ADDRESS and else case to create InetAddressAndPort
instances
with DatabaseDescriptor.getNativeTransportPort and returns the
getHostAddress(withPort) which properly bracket encodes the address,
e.g.:
[0:0:0:0:0:0:5a:3]:9042
which can be parsed as an InetSocketAddress.
---
.../apache/cassandra/service/StorageService.java | 27 +++---
.../service/StorageServiceServerTest.java | 22 ++
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index 7e70e4ce20..b70347a301 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -1975,10 +1975,31 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
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();
+{
+ final String ipAddress;
+ // If RPC_ADDRESS present in gossip for this endpoint use it.
This is expected for 3.x nodes.
+ if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
!= null)
+ {
+ ipAddress =
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value;
+ }
+ else
+ {
+ // otherwise just use the IP of the endpoint itself.
+ ipAddress = endpoint.getHostAddress(false);
+ }
+
+ // include the configured native_transport_port.
+ try
+ {
+ InetAddressAndPort address =
InetAddressAndPort.getByNameOverrideDefaults(ipAddress,
DatabaseDescriptor.getNativeTransportPort());
+ return address.getHostAddress(withPort);
+ }
+ catch (UnknownHostException e)
+ {
+ throw new RuntimeException(e);
+ }
+ }
}
public Map, List> getRangeToRpcaddressMap(String
keyspace)
diff --git
a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
index b5ddd35514..60bed4c64d 100644
--- a/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
+++ b/test/unit/org/apache/cassandra/service/StorageServiceServerTest.java
@@ -641,6 +641,28 @@ public class StorageServiceServerTest
assertEquals("127.0.0.3:666",
StorageService.instance.getNativeaddress(internalAddress, true));
}
+@Test
+public void testGetNativeAddressIPV6() throws Exception
+{
+// Ensure IPv6 addresses are properly bracketed in RFC2732
(https://datatracker.ietf.org/doc/html/rfc2732) format when including ports.
+// See https://issues.apache.org/jira/browse/CASSANDRA-17945 for more
context.
+String internalAddressIPV6String = "[0:0:0:0:0:0:0:3]:666";
+InetAddressAndPort internalAddressIPV6 =
InetAddressAndPort.getByName(internalAddressIPV6String);
+Gossiper.instance.addSavedEndpoint(internalAddressIPV6);
+
+//Default to using the provided address with the configured port
+assertEquals("[0:0:0:0:0:0:0:3]:" +
DatabaseDescriptor.getNativeTransportPort(),
StorageService.instance.getNativeaddress(internalAddressIPV6, true));
+
+VersionedValue.VersionedValueFactory valueFactory = new
[cassandra] branch cassandra-17945-4.0-guest created (now c50ab51411)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch cassandra-17945-4.0-guest in repository https://gitbox.apache.org/repos/asf/cassandra.git at c50ab51411 Update StorageService.getNativeaddress to handle IPv6 addresses This branch includes the following new commits: new c50ab51411 Update StorageService.getNativeaddress to handle IPv6 addresses 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613735#comment-17613735 ] Brandon Williams edited comment on CASSANDRA-17948 at 10/6/22 5:50 PM: --- I don't think parsing it from disk is going to be compatible with all the possible logging configurations (some might not even log _to disk_) and formats so doing it inside-out with the appender is going to be a strong advantage. was (Author: brandon.williams): I don't think parsing it from disk is going to be compatible with all the possible logging configurations (some might not even log _to disk_) so doing it inside-out with the appender is going to be a strong advantage. > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian Jira (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-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613735#comment-17613735 ] Brandon Williams commented on CASSANDRA-17948: -- I don't think parsing it from disk is going to be compatible with all the possible logging configurations (some might not even log _to disk_) so doing it inside-out with the appender is going to be a strong advantage. > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian Jira (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-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613731#comment-17613731 ] Josh McKenzie commented on CASSANDRA-12106: --- Chatting w/Stefan offline about this a bit. Initial thoughts: 1. Guardrail w/warn and fail threshold sounds useful 2. Don't see much risk of cascading failure or issues from a PK auto-deny at threshold 3. Being able to configure this on a per-table or per-column level could also be pretty useful but that's a bigger longer-term thing since that'd require metadata / file format changes or some other mapping so worth doing the simple clean thing first. Worth opening a follow-up JIRA for IMO for sure. > Add ability to blocklist / denylist a CQL partition so all requests are > ignored > --- > > Key: CASSANDRA-12106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12106 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Local Write-Read Paths, Local/Config >Reporter: Geoffrey Yu >Assignee: Josh McKenzie >Priority: Low > Fix For: 4.1-alpha1, 4.1 > > Attachments: 12106-trunk.txt > > > Sometimes reads/writes to a given partition may cause problems due to the > data present. It would be useful to have a manual way to blocklist / denylist > such partitions so all read and write requests to them are rejected. -- This message was sent by Atlassian Jira (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
]
Michael Semb Wever updated CASSANDRA-17879:
---
Fix Version/s: 4.1-beta2
4.1
(was: 4.1-rc)
> 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.28, 3.11.14, 4.0.7, 4.1-beta2, 4.1, 4.2
>
> 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-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613730#comment-17613730 ] Josh McKenzie commented on CASSANDRA-17948: --- bq. Rather than dealing with storing all the log messages on disk and in memory, what about reading the actual logs off disk when the virtual table is accessed? bq. this way you could speed things up if you ask for example every time the last 5 min of logs. My assumption is that Jon's initial approach (parse it off disk when queried from virtual table) would be plenty fast for either the human-exploring use-case _or_ the "automated tool polls once a minute" case. There's the big benefit that we get access to basically all the log messages the node has available via that approach vs. having the rolling buffer of X entries which potentially introduces another configurable knob for folks to worry about. > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian Jira (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-17927) Test Failure: org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc
[
https://issues.apache.org/jira/browse/CASSANDRA-17927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17927:
---
Fix Version/s: 4.1-beta2
4.1
(was: 4.1-beta1)
> Test Failure:
> org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc
>
> ---
>
> Key: CASSANDRA-17927
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17927
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1-beta2, 4.1, 4.2
>
>
> [Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.transport/RateLimitingTest/shouldThrowOnOverloadSmallMessages_4_v4__cdc/]
> Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%
> Error Message
> expected:<0> but was:<316>
> StackTrace
> {code:java}
> junit.framework.AssertionFailedError: expected:<0> but was:<316>
> at
> org.apache.cassandra.transport.RateLimitingTest.testOverload(RateLimitingTest.java:198)
> at
> org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages(RateLimitingTest.java:111)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {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-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=17613729#comment-17613729
]
Natnael Adere commented on CASSANDRA-17915:
---
Hey [~blerer], can you please review the patch linked above?
> 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-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613725#comment-17613725
]
Brandon Williams commented on CASSANDRA-17945:
--
Might as well be me :) +1
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
>
[jira] [Updated] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17945:
-
Change Category: Operability
Complexity: Normal
Fix Version/s: 4.0.x
4.1-rc
Reviewers: Ariel Weisberg, Brandon Williams (was: Ariel Weisberg)
Status: Open (was: Triage Needed)
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
>
[jira] [Comment Edited] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613722#comment-17613722
]
Ariel Weisberg edited comment on CASSANDRA-17945 at 10/6/22 5:09 PM:
-
TY [~brandon.williams]! Will find a second reviewer.
was (Author: aweisberg):
TY Brandon! Will find a second reviewer.
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
[jira] [Commented] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613722#comment-17613722
]
Ariel Weisberg commented on CASSANDRA-17945:
TY Brandon! Will find a second reviewer.
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> 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
>Priority: Normal
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> 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
>
[jira] [Assigned] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Chen-Becker reassigned CASSANDRA-17950: - Assignee: Derek Chen-Becker > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > -- This message was sent by Atlassian Jira (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-17950) Enable dtest-offheap in CircleCI
Derek Chen-Becker created CASSANDRA-17950: - Summary: Enable dtest-offheap in CircleCI Key: CASSANDRA-17950 URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 Project: Cassandra Issue Type: Sub-task Reporter: Derek Chen-Becker -- This message was sent by Atlassian Jira (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-17939) CircleCI: Automatically detect and repeat new or modified JUnit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613712#comment-17613712
]
Andres de la Peña edited comment on CASSANDRA-17939 at 10/6/22 5:02 PM:
I'm glad you both like it :)
On a further refinement, I have added support for specifying particular method
names in the lists of test classes that are manually passed to the companion
jobs. For example:
{code:java}
.circleci/generate.sh -m \
-e REPEATED_TESTS_COUNT=5 \
-e
REPEATED_UTESTS=org.apache.cassandra.cql3.DurationTest#testAddTo,org.apache.cassandra.cql3.validation.entities.DateTypeTest
\
-e REPEATED_UTESTS_COUNT=10 \
-e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AlterTest#getAndSetCompressionParametersTest
\
-e REPEATED_JVM_DTESTS_COUNT=10 \
-e
REPEATED_UTESTS_LONG=org.apache.cassandra.io.sstable.CQLSSTableWriterLongTest#testWideRow
\
-e REPEATED_UTESTS_LONG_COUNT=2
{code}
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1899]|[j8_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/d470fdb7-c321-4f18-82b5-6eac6d7c0992]
[j11_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/2bd34d9e-a32e-460d-a075-8ffdf7db4f09]
[j8_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/3018332a-0c93-4e27-918f-48e4166de932]
[j11_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/56c80e7d-d3f4-4e46-ba9a-021e80cf9314]|
We can see on [the artifacts
tabs|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/d470fdb7-c321-4f18-82b5-6eac6d7c0992/jobs/21753/artifacts]
that the jobs are running the manually specified test classes and methods,
together with the automatically detected tests that come from [this test
commit|https://github.com/adelapena/cassandra/commit/6639cc5d1c39080da271ef8a5c8d8366a5b713af].
With this changes the new companion jobs are mostly equivalent in functionality
to the classic utest multiplexer. The only relevant thing that is missing in
the new companion jobs is that the classic utest multiplexer is able to run any
Ant target, and we don't have regular not-multiplexer jobs for some Ant
targets, like {{test-cdc}} or {{{}msg-ser-test{}}}.
I guess that someday we'll manage to get CircleCI jobs for every possible type
of test, all of them with its companion multiplexer job. That day we could
probably get rid of the classic utest multiplexer.
In the meantime, I wonder if we should remove the classic utest multiplexer
from the pre-commit workflows and leave it only on the separate workflows. Or
perhaps move it to a separate workflow dedicated to that kind of debugging.
After all, the sole purpose of the classic utest multiplexer will be
reproducing existing flakies.
was (Author: adelapena):
I'm glad you both like it :)
On a further refinement, I have added support for specifying particular method
names in the lists of test classes that are manually passed to the companion
jobs. For example:
{code:java}
.circleci/generate.sh -m \
-e REPEATED_TESTS_COUNT=5 \
-e
REPEATED_UTESTS=org.apache.cassandra.cql3.DurationTest#testAddTo,org.apache.cassandra.cql3.validation.entities.DateTypeTest
\
-e REPEATED_UTESTS_COUNT=10 \
-e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AlterTest#getAndSetCompressionParametersTest
\
-e REPEATED_JVM_DTESTS_COUNT=10 \
-e
REPEATED_UTESTS_LONG=org.apache.cassandra.io.sstable.CQLSSTableWriterLongTest#testWideRow
\
-e REPEATED_UTESTS_LONG_COUNT=2
{code}
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1899]|[j8_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/d470fdb7-c321-4f18-82b5-6eac6d7c0992]
[j11_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/2bd34d9e-a32e-460d-a075-8ffdf7db4f09]
[j8_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/3018332a-0c93-4e27-918f-48e4166de932]
[j11_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/56c80e7d-d3f4-4e46-ba9a-021e80cf9314]|
We can see on [the artifacts
tabs|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/d470fdb7-c321-4f18-82b5-6eac6d7c0992/jobs/21753/artifacts]
that the jobs are running the manually specified test classes and methods,
together with the automatically detected tests that come from [this test
commit|https://github.com/adelapena/cassandra/commit/6639cc5d1c39080da271ef8a5c8d8366a5b713af].
With this changes the new companion jobs are mostly equivalent in functionality
to the classic utest multiplexer. The only relevant thing that is missing in
the new companion jobs is that the classic utest multiplexer is able to run any
Ant target, and we don't have
[jira] [Commented] (CASSANDRA-17939) CircleCI: Automatically detect and repeat new or modified JUnit tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613712#comment-17613712
]
Andres de la Peña commented on CASSANDRA-17939:
---
I'm glad you both like it :)
On a further refinement, I have added support for specifying particular method
names in the lists of test classes that are manually passed to the companion
jobs. For example:
{code:java}
.circleci/generate.sh -m \
-e REPEATED_TESTS_COUNT=5 \
-e
REPEATED_UTESTS=org.apache.cassandra.cql3.DurationTest#testAddTo,org.apache.cassandra.cql3.validation.entities.DateTypeTest
\
-e REPEATED_UTESTS_COUNT=10 \
-e
REPEATED_JVM_DTESTS=org.apache.cassandra.distributed.test.AlterTest#getAndSetCompressionParametersTest
\
-e REPEATED_JVM_DTESTS_COUNT=10 \
-e
REPEATED_UTESTS_LONG=org.apache.cassandra.io.sstable.CQLSSTableWriterLongTest#testWideRow
\
-e REPEATED_UTESTS_LONG_COUNT=2
{code}
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1899]|[j8_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/d470fdb7-c321-4f18-82b5-6eac6d7c0992]
[j11_pre-commit|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/2bd34d9e-a32e-460d-a075-8ffdf7db4f09]
[j8_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/3018332a-0c93-4e27-918f-48e4166de932]
[j11_separate|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/56c80e7d-d3f4-4e46-ba9a-021e80cf9314]|
We can see on [the artifacts
tabs|https://app.circleci.com/pipelines/github/adelapena/cassandra/2157/workflows/d470fdb7-c321-4f18-82b5-6eac6d7c0992/jobs/21753/artifacts]
that the jobs are running the manually specified test classes and methods,
together with the automatically detected tests that come from [this test
commit|https://github.com/adelapena/cassandra/commit/6639cc5d1c39080da271ef8a5c8d8366a5b713af].
With this changes the new companion jobs are mostly equivalent in functionality
to the classic utest multiplexer. The only relevant thing that is missing in
the new companion jobs is that the classic utest multiplexer is able to run any
Ant target, and we don't have regular not-multiplexer jobs for some Ant
targets, like {{test-cdc}} or {{{}msg-ser-test{}}}.
I guess that someday we'll manage to get CircleCI jobs for every possible type
of test, all of them with its companion multiplexer job. That day we could
probably get rid of the classic utest multiplexer. In the meantime, I wonder if
we should remove the classic utest multiplexer from the pre-commit workflows
and leave it only on the separate workflows. After all, its sole purpose will
be reproducing existing flakies, and we usually do that with the separate
workflows.
> CircleCI: Automatically detect and repeat new or modified JUnit tests
> -
>
> Key: CASSANDRA-17939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17939
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The purpose of this ticket is adding a new CircleCI job that automatically
> detects new or modified test classes and runs them repeatedly. That way we
> wouldn't need to manually specify those tests with {{.circleci/generate.sh}}.
--
This message was sent by Atlassian 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 (ba1a3fb8ae -> 472dc30faa)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from ba1a3fb8ae Merge branch 'cassandra-4.1' into trunk add 0c4daa1ddc Fix up CHANGES.txt chaos add fb4974d455 Merge branch 'cassandra-4.0' into cassandra-4.1 new 472dc30faa Merge branch 'cassandra-4.1' into trunk 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: CHANGES.txt | 67 + 1 file changed, 14 insertions(+), 53 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 472dc30faa7e23990d7fbd585cf8409659926004 Merge: ba1a3fb8ae fb4974d455 Author: Aleksey Yeschenko AuthorDate: Thu Oct 6 17:04:20 2022 +0100 Merge branch 'cassandra-4.1' into trunk CHANGES.txt | 67 + 1 file changed, 14 insertions(+), 53 deletions(-) diff --cc CHANGES.txt index b9006d8904,41a625cec9..3c4c1785d2 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -151,9 -58,15 +110,17 @@@ Merged from 4.0 * Ensure FileStreamTask cannot compromise shared channel proxy for system table when interrupted (CASSANDRA-17663) * silence benign SslClosedEngineException (CASSANDRA-17565) Merged from 3.11: ++ * Make LongBufferPoolTest insensitive to timing (CASSANDRA-16681) + * Fix potential IndexOutOfBoundsException in PagingState in mixed mode clusters (CASSANDRA-17840) + * Document usage of closed token intervals in manual compaction (CASSANDRA-17575) + * Creating of a keyspace on insufficient number of replicas should filter out gosspping-only members (CASSANDRA-17759) + * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) Merged from 3.0: - * Fix writetime and ttl functions forbidden for collections instead of multicell columns (CASSANDRA-17628) - ++ * Fix auto-completing "WITH" when creating a materialized view (CASSANDRA-17879) + * Improve libjemalloc resolution in bin/cassandra (CASSANDRA-15767) + * Fix restarting of services on gossipping-only member (CASSANDRA-17752) + * Fix scrubber falling into infinite loop when the last partition is broken (CASSANDRA-17862) + * Fix resetting schema (CASSANDRA-17819) 4.1-alpha1 * Handle config parameters upper bound on startup; Fix auto_snapshot_ttl and paxos_purge_grace_period min unit validations (CASSANDRA-17571) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (4e1d31e729 -> 0c4daa1ddc)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 4e1d31e729 Merge branch 'cassandra-3.11' into cassandra-4.0 add 0c4daa1ddc Fix up CHANGES.txt chaos No new revisions were added by this update. Summary of changes: CHANGES.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (0b083d3e73 -> fb4974d455)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 0b083d3e73 Merge branch 'cassandra-4.0' into cassandra-4.1 add 0c4daa1ddc Fix up CHANGES.txt chaos add fb4974d455 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt | 54 -- 1 file changed, 12 insertions(+), 42 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17922) Jolokia agent fails to connect though port is available
[
https://issues.apache.org/jira/browse/CASSANDRA-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613693#comment-17613693
]
Brandon Williams commented on CASSANDRA-17922:
--
It's not the port after CASSANDRA-17872, so it's down to some internal java
agent thing.
> Jolokia agent fails to connect though port is available
> ---
>
> Key: CASSANDRA-17922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17922
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> In CASSANDRA-17872 we added protection around failures similar to this,
> caused by the port being in use, which is no longer the case:
> {code}
> subprocess.CalledProcessError: Command
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '{-}cp',
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
> 'org.jolokia.jvmagent.client.AgentLauncher', '{-}{-}host', '127.0.0.2',
> '{-}-port', '8778', 'start', '1123')' returned non-zero exit status 1.
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/junit/dtest-novnode.auth_test/TestNetworkAuth/test_revoked_dc_access/]
--
This message was sent by Atlassian Jira
(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-17922) Jolokia agent fails to connect though port is available
[
https://issues.apache.org/jira/browse/CASSANDRA-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613689#comment-17613689
]
Josh McKenzie commented on CASSANDRA-17922:
---
Do we know the source of the race that's leading to the port being in use? i.e.
is there something underlying (non-deterministic timing on cluster setup /
teardown / agent init / etc) that we could block on to get a bit more guarantee
on this rather than sleeping?
> Jolokia agent fails to connect though port is available
> ---
>
> Key: CASSANDRA-17922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17922
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> In CASSANDRA-17872 we added protection around failures similar to this,
> caused by the port being in use, which is no longer the case:
> {code}
> subprocess.CalledProcessError: Command
> '('/usr/lib/jvm/java-8-openjdk-amd64/bin/java', '{-}cp',
> '/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar:/home/cassandra/cassandra/cassandra-dtest/tools/../lib/jolokia-jvm-1.7.1-agent.jar',
> 'org.jolokia.jvmagent.client.AgentLauncher', '{-}{-}host', '127.0.0.2',
> '{-}-port', '8778', 'start', '1123')' returned non-zero exit status 1.
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/junit/dtest-novnode.auth_test/TestNetworkAuth/test_revoked_dc_access/]
--
This message was sent by Atlassian Jira
(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-17575) forceCompactionForTokenRange when using a wrapped range may include sstables not within that range
[ https://issues.apache.org/jira/browse/CASSANDRA-17575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17575: -- Fix Version/s: 4.1-beta1 (was: 4.1-alpha1) > forceCompactionForTokenRange when using a wrapped range may include sstables > not within that range > -- > > Key: CASSANDRA-17575 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17575 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: David Capwell >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.11.14, 4.0.6, 4.1-beta1, 4.1, 4.2 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > This was found in CASSANDRA-17537 > When you compact the range (32, 31] this should include everything BUT 32, > but in the test > org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction > it found that SSTables with the bounds (32, 32) were getting included in the > set of SSTables to compact -- This message was sent by Atlassian Jira (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-17840) IndexOutOfBoundsException in Paging State Version Inference (V3 State Received on V4 Connection)
[
https://issues.apache.org/jira/browse/CASSANDRA-17840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-17840:
--
Fix Version/s: 4.1-beta1
(was: 4.1)
> IndexOutOfBoundsException in Paging State Version Inference (V3 State
> Received on V4 Connection)
>
>
> Key: CASSANDRA-17840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17840
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 3.11.14, 4.0.6, 4.1-beta1, 4.2
>
>
> In {{PagingState.java}}, {{index}} is an integer field, and we add long
> values to it without a {{Math.toIntExact}} check. While we’re checking for
> negative return values returned by {{getUnsignedVInt}}, there's a chance that
> the value returned by it is so large that addition operation would cause
> integer overflow, or the value itself is large enough to cause overflow.
--
This message was sent by Atlassian Jira
(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-17731) Clean up ScheduledExecutors, CommitLog, and MessagingService shutdown for in-JVM dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-17731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-17731:
--
Fix Version/s: 4.1-beta1
(was: 4.1)
> Clean up ScheduledExecutors, CommitLog, and MessagingService shutdown for
> in-JVM dtests
> ---
>
> Key: CASSANDRA-17731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17731
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.6, 4.1-beta1, 4.2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> There appear to be two problems w/ the way we shut down
> {{ScheduledExecutors}} in Instance in 4.0+:
> 1.) We do it twice, Ince as part of a larger batch of shutdown activity, and
> then again in its own {{parallelRun()}} block.
> 2.) It happens before {{MessagingService}} shuts down, but some
> messaging-related threads (see {{StreamSession#closeSession()}}) can submit
> tasks to {{nonPeriodicTasks}}.
> We should do it once, and do it after the {{MessagingService}} has properly
> shut down.
--
This message was sent by Atlassian Jira
(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-17792) Fix race condition on updating cdc size and advancing to next segment
[
https://issues.apache.org/jira/browse/CASSANDRA-17792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-17792:
--
Fix Version/s: 4.1-beta1
(was: 4.1.x)
> Fix race condition on updating cdc size and advancing to next segment
> -
>
> Key: CASSANDRA-17792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17792
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0.6, 4.1-beta1, 4.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> org.apache.cassandra.distributed.test.cdc.ToggleCDCOnRepairEnabledTest is a
> bit flaky on [trunk.
> As [this
> run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=17666]
> shows it was flaky since it was introduced a month ago as part of
> CASSANDRA-17666 but the flakiness is so low that if we don't run it in a loop
> it is hard to hit it.
> Both tests in the test class can fail with the same exception:
> {code:java}
> org.apache.cassandra.distributed.shared.ShutdownException: Uncaught
> exceptions were thrown during test at
> org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
> at
> org.apache.cassandra.distributed.test.cdc.ToggleCDCOnRepairEnabledTest.testCDCOnRepairEnabled(ToggleCDCOnRepairEnabledTest.java:95)
> at
> org.apache.cassandra.distributed.test.cdc.ToggleCDCOnRepairEnabledTest.testCDCOnRepairIsEnabled(ToggleCDCOnRepairEnabledTest.java:40)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Suppressed: java.lang.NullPointerException at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDC$CDCSizeTracker.recalculateOverflowSize(CommitLogSegmentManagerCDC.java:390)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81) at
> org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at
> org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829){code}
> CC [~ycai] , [~jmckenzie]
--
This message was sent by Atlassian Jira
(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=17613600#comment-17613600 ] Derek Chen-Becker commented on CASSANDRA-17930: --- I think there's material evidence (e.g. this ticket) that the current approach has problems. In the short term, I think we need to just manually turn the crank to fix up what we can find. What I mean by a long-term driven by a single config is it would be ideal to have a (simple) way to define a test in one place, and be able to generate the configurations for CircleCI, Jenkins, and whatever other CI system we decide to use from that canonical source. I'm not saying that this ticket is where this happens, I'm just saying a system where you rely on good intentions to ensure parity is statistically unlikely to maintain that parity over time. As for naming, I'm fine taking small incremental steps to fix them, but I do think they need fixed. I don't see any value in having the names not be the same between the two systems. If changing the name of a test doesn't otherwise change or break its behavior, do you have an objection? > 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
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ba1a3fb8ae92f51965d4771738d55a2163490c70 Merge: ace5662143 0b083d3e73 Author: Aleksey Yeschenko AuthorDate: Thu Oct 6 15:36:57 2022 +0100 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 2 + .../apache/cassandra/utils/memory/BufferPool.java | 24 +++ .../cassandra/utils/memory/LongBufferPoolTest.java | 219 +++-- .../cassandra/utils/memory/BufferPoolTest.java | 31 +++ 4 files changed, 219 insertions(+), 57 deletions(-) diff --cc CHANGES.txt index 72e7720b73,d52a47dca7..b9006d8904 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -111,6 -59,6 +111,7 @@@ Merged from 4.0 * Avoid getting hanging repairs due to repair message timeouts (CASSANDRA-17613) * Prevent infinite loop in repair coordinator on FailSession (CASSANDRA-17834) Merged from 3.11: ++ * Make LongBufferPoolTest insensitive to timing (CASSANDRA-16681) * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) * Fix potential IndexOutOfBoundsException in PagingState in mixed mode clusters (CASSANDRA-17840) Merged from 3.0: @@@ -118,6 -65,6 +119,7 @@@ * Fix scrubber falling into infinite loop when the last partition is broken (CASSANDRA-17862) * Fix resetting schema (CASSANDRA-17819) ++ 4.0.6 * Prevent infinite loop in repair coordinator on FailSession (CASSANDRA-17834) * Fix race condition on updating cdc size and advancing to next segment (CASSANDRA-17792) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (ace5662143 -> ba1a3fb8ae)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from ace5662143 Merge branch 'cassandra-4.1' into trunk add dc2acba043 Make LongBufferPoolTest insensitive to timing add 4e1d31e729 Merge branch 'cassandra-3.11' into cassandra-4.0 add 0b083d3e73 Merge branch 'cassandra-4.0' into cassandra-4.1 new ba1a3fb8ae Merge branch 'cassandra-4.1' into trunk 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: CHANGES.txt| 2 + .../apache/cassandra/utils/memory/BufferPool.java | 24 +++ .../cassandra/utils/memory/LongBufferPoolTest.java | 219 +++-- .../cassandra/utils/memory/BufferPoolTest.java | 31 +++ 4 files changed, 219 insertions(+), 57 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (e9b411e3e0 -> 4e1d31e729)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from e9b411e3e0 Merge branch 'cassandra-3.11' into cassandra-4.0 add dc2acba043 Make LongBufferPoolTest insensitive to timing add 4e1d31e729 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/utils/memory/BufferPool.java | 24 +++ .../cassandra/utils/memory/LongBufferPoolTest.java | 220 +++-- .../cassandra/utils/memory/BufferPoolTest.java | 31 +++ 4 files changed, 219 insertions(+), 57 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (c4bccb000a -> 0b083d3e73)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from c4bccb000a Increment version to 4.1-beta2 add dc2acba043 Make LongBufferPoolTest insensitive to timing add 4e1d31e729 Merge branch 'cassandra-3.11' into cassandra-4.0 add 0b083d3e73 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 3 +- .../apache/cassandra/utils/memory/BufferPool.java | 24 +++ .../cassandra/utils/memory/LongBufferPoolTest.java | 219 +++-- .../cassandra/utils/memory/BufferPoolTest.java | 31 +++ 4 files changed, 219 insertions(+), 58 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (ad6bca4ab5 -> dc2acba043)
This is an automated email from the ASF dual-hosted git repository. aleksey pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from ad6bca4ab5 Merge branch 'cassandra-3.0' into cassandra-3.11 add dc2acba043 Make LongBufferPoolTest insensitive to timing No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/utils/memory/BufferPool.java | 46 - .../cassandra/utils/memory/LongBufferPoolTest.java | 192 +++-- 3 files changed, 186 insertions(+), 53 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17894) Test Failure: dtest-large.topology_test.TestTopology.test_stop_decommission_too_few_replicas_multi_dc
[
https://issues.apache.org/jira/browse/CASSANDRA-17894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613571#comment-17613571
]
Brandon Williams commented on CASSANDRA-17894:
--
The logs indicate node4 never received the 'create ks' mutation, only the
system_distributed change, and then the request to drop 'ks' which caused this
error. Given that this only repros on occasion in Jenkins, I'm blocking this
on CASSANDRA-17932 since there's nothing obvious left to take a shot in the
dark at like before.
> Test Failure:
> dtest-large.topology_test.TestTopology.test_stop_decommission_too_few_replicas_multi_dc
>
> --
>
> Key: CASSANDRA-17894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17894
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc, 4.1
>
>
> Link to failure:
> https://ci-cassandra.apache.org/job/Cassandra-4.1/162/testReport/dtest-large.topology_test/TestTopology/test_stop_decommission_too_few_replicas_multi_dc/
> Error Message
> test teardown failure
> Stacktrace
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [OptionalTasks:1] 2022-09-13 02:10:09,576
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[OptionalTasks:1,5,OptionalTasks]\njava.lang.AssertionError: Unknown
> keyspace ks\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:339)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:163)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:228)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:163)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:152)\n\tat
> com.google.common.collect.Iterators$6.transform(Iterators.java:785)\n\tat
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47)\n\tat
>
> org.apache.cassandra.db.SizeEstimatesRecorder.run(SizeEstimatesRecorder.java:74)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:748)']
> {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-17894) Test Failure: dtest-large.topology_test.TestTopology.test_stop_decommission_too_few_replicas_multi_dc
[
https://issues.apache.org/jira/browse/CASSANDRA-17894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17894:
-
Fix Version/s: 4.1-rc
(was: 4.1-beta)
> Test Failure:
> dtest-large.topology_test.TestTopology.test_stop_decommission_too_few_replicas_multi_dc
>
> --
>
> Key: CASSANDRA-17894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17894
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1-rc, 4.1
>
>
> Link to failure:
> https://ci-cassandra.apache.org/job/Cassandra-4.1/162/testReport/dtest-large.topology_test/TestTopology/test_stop_decommission_too_few_replicas_multi_dc/
> Error Message
> test teardown failure
> Stacktrace
> {code}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [OptionalTasks:1] 2022-09-13 02:10:09,576
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[OptionalTasks:1,5,OptionalTasks]\njava.lang.AssertionError: Unknown
> keyspace ks\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:339)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:163)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:228)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:163)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:152)\n\tat
> com.google.common.collect.Iterators$6.transform(Iterators.java:785)\n\tat
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47)\n\tat
>
> org.apache.cassandra.db.SizeEstimatesRecorder.run(SizeEstimatesRecorder.java:74)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.lang.Thread.run(Thread.java:748)']
> {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-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=17613564#comment-17613564 ] Jon Meredith commented on CASSANDRA-17923: -- +1 from me too. > 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-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613555#comment-17613555 ] Brandon Williams commented on CASSANDRA-17948: -- bq. we should expose this information about large partitions directly into some cql virtual table +1, that should be its own ticket and done in a more focused way. bq. that buffer would have a constant size, e.g. 10k lines, messages would be added on top and if the buffer is full, the oldest message would be dropped This sounds like a good approach for this ticket. > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian Jira (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-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613506#comment-17613506 ] Stefan Miklosovic commented on CASSANDRA-17948: --- [~MichielSA] I added my POC for auto-denying as the last comment in this ticket https://issues.apache.org/jira/browse/CASSANDRA-12106 > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian Jira (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-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613504#comment-17613504 ] Stefan Miklosovic edited comment on CASSANDRA-12106 at 10/6/22 1:05 PM: Would it be interesting for people to have auto-deny capability? It would autodeny partitions which are logged as too big upon writing sstables to disk. Until new sstable is written, it would still accept these big rows but as soon as BigTableWriter realises it is too large, why not to autodeny it so that partition will never be written again? Right now, it is quite tedious task to look into logs to see what is too large to investigate it and to put it into denylist. Couldnt this be automated? the very early POC is here [https://github.com/instaclustr/cassandra/commit/bd88d6dc1618bd618b5a6059097cb466ab13c110] was (Author: smiklosovic): Would it be interesting for people to have auto-deny capability? It would autodeny partitions which are logged as too big upon writing sstables to disk. Until new sstable is written, it would still accept these big rows but as soon as BigTableWriter realises it is too large, why not to autodeny it so that partition will never be written again? the very early POC is here https://github.com/instaclustr/cassandra/commit/bd88d6dc1618bd618b5a6059097cb466ab13c110 > Add ability to blocklist / denylist a CQL partition so all requests are > ignored > --- > > Key: CASSANDRA-12106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12106 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Local Write-Read Paths, Local/Config >Reporter: Geoffrey Yu >Assignee: Josh McKenzie >Priority: Low > Fix For: 4.1-alpha1, 4.1 > > Attachments: 12106-trunk.txt > > > Sometimes reads/writes to a given partition may cause problems due to the > data present. It would be useful to have a manual way to blocklist / denylist > such partitions so all read and write requests to them are rejected. -- This message was sent by Atlassian Jira (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-12106) Add ability to blocklist / denylist a CQL partition so all requests are ignored
[ https://issues.apache.org/jira/browse/CASSANDRA-12106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613504#comment-17613504 ] Stefan Miklosovic commented on CASSANDRA-12106: --- Would it be interesting for people to have auto-deny capability? It would autodeny partitions which are logged as too big upon writing sstables to disk. Until new sstable is written, it would still accept these big rows but as soon as BigTableWriter realises it is too large, why not to autodeny it so that partition will never be written again? the very early POC is here https://github.com/instaclustr/cassandra/commit/bd88d6dc1618bd618b5a6059097cb466ab13c110 > Add ability to blocklist / denylist a CQL partition so all requests are > ignored > --- > > Key: CASSANDRA-12106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12106 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Local Write-Read Paths, Local/Config >Reporter: Geoffrey Yu >Assignee: Josh McKenzie >Priority: Low > Fix For: 4.1-alpha1, 4.1 > > Attachments: 12106-trunk.txt > > > Sometimes reads/writes to a given partition may cause problems due to the > data present. It would be useful to have a manual way to blocklist / denylist > such partitions so all read and write requests to them are rejected. -- This message was sent by Atlassian 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 (59983b39 -> 7d4a7d69)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 59983b39 generate docs for 2af01b8f new 7d4a7d69 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 (59983b39) \ N -- N -- N refs/heads/asf-staging (7d4a7d69) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17948) Get warning and errors through virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613424#comment-17613424
]
Stefan Miklosovic edited comment on CASSANDRA-17948 at 10/6/22 10:34 AM:
-
I have put my vision into this PR (1). Please try it and tell me if there are
any issues with that.
You can do, for example, these queries:
{code:java}
select timestamp,message from system_views.instance_logs where timestamp >
'2022-10-06 10:12:42+' AND timestamp < '2022-10-06 10:13:30+' AND level
= 'INFO' ALLOW FILTERING;
{code}
The reason there is "order_in_millisecond" column introduced is that logging
message contains resolution in milliseconds but there are some cases when we
have multiple messages withing that millisecond. If we didnt have
order_in_millisecond column, it might happen that one message would replace
another on insert as it would be of same milliseconds as the previous one.
Hence, we have millisecond-wide partition.
I have also added the logging level among clustering columns so you can filter
on that. I would say that using ALLOW FITLERING on tables like these is OK.
_If the query would fail in this case, would it be possible to tell it is
because of the partition size?_
Is not this already case? I am not familiar with denylist mechanism (2) but I
would expect that if you try to insert something into a partition which is too
big, it would tell you what partition it is? Maybe try to re-formulate your
question, please.
(1) [https://github.com/apache/cassandra/pull/1900]
(2)
[https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions]
was (Author: smiklosovic):
I have put my vision into this PR (1). Please try it and tell me if there are
any issues with that.
You can do, for example, these queries:
{code}
select timestamp,message from system_views.instance_logs where timestamp >
'2022-10-06 10:12:42+' AND timestamp < '2022-10-06 10:13:30+' AND level
= 'INFO' ALLOW FILTERING;
{code}
The reason there is "order_in_millisecond" column introduced is that logging
message contains resolution in milliseconds but there are some cases when we
have multiple messages withing that millisecond. If we didnt have
order_in_millisecond column, it might happen that one message would replace
another on insert as it would be of same milliseconds as the previous one.
Hence, we have millisecond-wide partition.
I have also added the logging level among clustering columns so you can filter
on that. I would say that using ALLOW FITLERING on tables like these is OK.
_ If the query would fail in this case, would it be possible to tell it is
because of the partition size?_
Is not this already case? I am not familiar with denylist mechanism but I would
expect that if you try to insert something into a partition which is too big,
it would tell you what partition it is? Maybe try to re-formulate your
question, please.
(1) https://github.com/apache/cassandra/pull/1900
> Get warning and errors through virtual tables
> -
>
> Key: CASSANDRA-17948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17948
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Michiel Saelen
>Priority: Normal
>
> The warnings and errors are currently only accessible through Cassandra logs.
> Automating the monitoring of the nodes would be much easier/secure if we can
> make use of virtual tables to get the logs.
--
This message was sent by Atlassian Jira
(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-17948) Get warning and errors through virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613424#comment-17613424
]
Stefan Miklosovic commented on CASSANDRA-17948:
---
I have put my vision into this PR (1). Please try it and tell me if there are
any issues with that.
You can do, for example, these queries:
{code}
select timestamp,message from system_views.instance_logs where timestamp >
'2022-10-06 10:12:42+' AND timestamp < '2022-10-06 10:13:30+' AND level
= 'INFO' ALLOW FILTERING;
{code}
The reason there is "order_in_millisecond" column introduced is that logging
message contains resolution in milliseconds but there are some cases when we
have multiple messages withing that millisecond. If we didnt have
order_in_millisecond column, it might happen that one message would replace
another on insert as it would be of same milliseconds as the previous one.
Hence, we have millisecond-wide partition.
I have also added the logging level among clustering columns so you can filter
on that. I would say that using ALLOW FITLERING on tables like these is OK.
_ If the query would fail in this case, would it be possible to tell it is
because of the partition size?_
Is not this already case? I am not familiar with denylist mechanism but I would
expect that if you try to insert something into a partition which is too big,
it would tell you what partition it is? Maybe try to re-formulate your
question, please.
(1) https://github.com/apache/cassandra/pull/1900
> Get warning and errors through virtual tables
> -
>
> Key: CASSANDRA-17948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17948
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Michiel Saelen
>Priority: Normal
>
> The warnings and errors are currently only accessible through Cassandra logs.
> Automating the monitoring of the nodes would be much easier/secure if we can
> make use of virtual tables to get the logs.
--
This message was sent by Atlassian Jira
(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-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613361#comment-17613361 ] Michiel Saelen commented on CASSANDRA-17948: Hi [~smiklosovic], Indeed for our use case, it would be beneficial if you could expose the partitions that crossed the thresholds directly into a virtual table (or have Cassandra protect itself). Blocking further inserts on Cassandra's side sounds like a good improvement to ensure more stability. To give you an example, we noticed Cassandra was struggling during compaction and then noticed we had created a partition of 50G. If the query would fail in this case, would it be possible to tell it is because of the partition size? Next to this, I still believe that making logs available through virtual tables would also be a great feature. Thanks for your input on this > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian 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 (f4315820 -> 59983b39)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard f4315820 generate docs for 2af01b8f new 59983b39 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 (f4315820) \ N -- N -- N refs/heads/asf-staging (59983b39) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613331#comment-17613331 ] Stefan Miklosovic edited comment on CASSANDRA-17948 at 10/6/22 7:06 AM: Thanks for the field report, [~MichielSA]. It is always interesting to read about the issues users get into so we can make it easier for them. There are multiple issues I want to go through as your comment mixes few things together. Firstly, if we are already logging the information about what the large partitions are but then you are forced to go through the logs to actually see what they are so you can block them via "denylist" mechanism, correct? If that is true, we should expose this information about large partitions directly into some cql virtual table so you do not need to go through them. Parsing logs so you can deny it is quite uncomfortable anyway, is not it? Secondly, why aren't we automatically denying partitions when they are detected to be large? Ideally, you should not do anything. If Cassandra evaluates that the partition you are going to insert to is too large, why we have to deny it manually? Why does not Cassandra block that partition in denylist automatically for us so you do not have to deal with all this stuff in the first place? Of course, sometimes you do want to insert regardless of the size of partition even they are bigger than recommended because you just do not have any other option, but automatic denying might be configurable per table so if it occurs, that partition will be automatically denylisted. When it comes to logs, I think coding a custom slf4j appender is the most natural thing to implement. It is super easy. One caveat is that if we are selecting from that virtual table, the rows you get should be in reversed order. Basically, the newest log messages are last in the file but they should be first in the table because we can not expect people to "scroll down" to the end of cql output every time to see new messages. They should be at the very top. When it comes reading a file, we should then read it in a reversed order. Fortunately, there is (1) which is able to do that and we depend on apache-commons already so we do not need to add any new dependency. The problem with this approach is - what should be the primary key? Parsing the timestamp from a line of log message seems to be error-prone because users might have different formatting of timestamps set in logger configuration (message format). My idea of doing this to use CircularFifoBuffer (2) - we again already depend on this library. The basic idea behind this is that buffer would have a constant size, e.g. 10k lines, messages would be added on top and if the buffer is full, the oldest message would be dropped so new one can be inserted. By doing this, we would have constant size of the vtable and the log messages would be "rolled up" automatically. With compressing the messages, I think the cost of having 10k of messages in memory is peanuts. Even 100k is just fine. What do you think [~rustyrazorblade]? [~brandon.williams] (1) https://commons.apache.org/proper/commons-io/javadocs/api-release/org/apache/commons/io/input/ReversedLinesFileReader.html (2) https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.2/org/apache/commons/collections/buffer/CircularFifoBuffer.html was (Author: smiklosovic): Thanks for the field report, [~MichielSA]. It is always interesting to read about the issues users get into so we can make it easier for them. There are multiple issues I want to go through as your comment mixes few things together. Firstly, if we are already logging the information about what the large partitions are but then you are forced to go through the logs to actually see what they are so you can block them via "denylist" mechanism, correct? If that is true, we should expose this information about large partitions directly into some cql virtual table so you do not need to go through them. Parsing logs so you can deny it is quite uncomfortable anyway, is not it? Secondly, why aren't we automatically denying partitions when they are detected to be large? Ideally, you should not do anything. If Cassandra evaluates that the partition you are going to insert to is too large, why we have to deny it manually? Why does not Cassandra block that partition in denylist automatically for us so you do not have to deal with all this stuff in the first place? Of course, sometimes you do want to insert regardless of the size of partition even they are bigger than recommended because you just do not have any other option, but automatic denying might be configurable per table so if it occurs, that partition will be automatically denylisted. When it comes to logs, I think coding a custom slf4j appender is the most natural thing to implement. It is
[jira] [Comment Edited] (CASSANDRA-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613331#comment-17613331 ] Stefan Miklosovic edited comment on CASSANDRA-17948 at 10/6/22 7:02 AM: Thanks for the field report, [~MichielSA]. It is always interesting to read about the issues users get into so we can make it easier for them. There are multiple issues I want to go through as your comment mixes few things together. Firstly, if we are already logging the information about what the large partitions are but then you are forced to go through the logs to actually see what they are so you can block them via "denylist" mechanism, correct? If that is true, we should expose this information about large partitions directly into some cql virtual table so you do not need to go through them. Parsing logs so you can deny it is quite uncomfortable anyway, is not it? Secondly, why aren't we automatically denying partitions when they are detected to be large? Ideally, you should not do anything. If Cassandra evaluates that the partition you are going to insert to is too large, why we have to deny it manually? Why does not Cassandra block that partition in denylist automatically for us so you do not have to deal with all this stuff in the first place? Of course, sometimes you do want to insert regardless of the size of partition even they are bigger than recommended because you just do not have any other option, but automatic denying might be configurable per table so if it occurs, that partition will be automatically denylisted. When it comes to logs, I think coding a custom slf4j appender is the most natural thing to implement. It is super easy. One caveat is that if we are selecting from that virtual table, the rows you get should be in reversed order. Basically, the newest log messages are last in the file but they should be first in the table because we can not expect people to "scroll down" to the end of cql output every time to see new messages. They should be at the very top. When it comes reading a file, we should then read it in a reversed order. Unfortunately, there is (1) which is able to do that and we depend on apache-commons already so we do not need to add any new dependency. The problem with this approach is - what should be the primary key? Parsing the timestamp from a line of log message seems to be error-prone because users might have different formatting of timestamps set in logger configuration (message format). My idea of doing this to use CircularFifoBuffer (2) - we again already depend on this library. The basic idea behind this is that buffer would have a constant size, e.g. 10k lines, messages would be added on top and if the buffer is full, the oldest message would be dropped so new one can be inserted. By doing this, we would have constant size of the vtable and the log messages would be "rolled up" automatically. With compressing the messages, I think the cost of having 10k of messages in memory is peanuts. Even 100k is just fine. What do you think [~rustyrazorblade]? [~brandon.williams] (1) https://commons.apache.org/proper/commons-io/javadocs/api-release/org/apache/commons/io/input/ReversedLinesFileReader.html (2) https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.2/org/apache/commons/collections/buffer/CircularFifoBuffer.html was (Author: smiklosovic): Thanks for the field report, [~MichielSA]. It is always interesting to read about the issues users get into so we can make it easier for them. There are multiple issues I want to go through as your comment mixes few things together. Firstly, if we are already logging the information about what the large partitions are but then you are forced to go through the logs to actually see what they are so you can block them via "denylist" mechanism, correct? If that is true, we should expose this information about large partitions directly into some cql virtual table so you do not need to go through them. Parsing logs so you can deny it is quite uncomfortable anyway, is not it? Secondly, why aret we automatically denying partitions when they are detected to be large? Ideally, you should not do anything. If Cassandra evaluates that the partition you are going to insert to is too large, why we have to deny it manually? Why does not Cassandra block that partition in denylist automatically for us so you do not have to deal with all this stuff in the first place? Of course, sometimes you do want to insert regardless of the size of partition even they are bigger than recommended because you just do not have any other option, but automatic denying might be configurable per table so if it occurs, that partition will be automatically denylisted. When it comes to logs, I think coding a custom slf4j appender is the most natural thing to implement. It is
[jira] [Commented] (CASSANDRA-17948) Get warning and errors through virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613331#comment-17613331 ] Stefan Miklosovic commented on CASSANDRA-17948: --- Thanks for the field report, [~MichielSA]. It is always interesting to read about the issues users get into so we can make it easier for them. There are multiple issues I want to go through as your comment mixes few things together. Firstly, if we are already logging the information about what the large partitions are but then you are forced to go through the logs to actually see what they are so you can block them via "denylist" mechanism, correct? If that is true, we should expose this information about large partitions directly into some cql virtual table so you do not need to go through them. Parsing logs so you can deny it is quite uncomfortable anyway, is not it? Secondly, why aret we automatically denying partitions when they are detected to be large? Ideally, you should not do anything. If Cassandra evaluates that the partition you are going to insert to is too large, why we have to deny it manually? Why does not Cassandra block that partition in denylist automatically for us so you do not have to deal with all this stuff in the first place? Of course, sometimes you do want to insert regardless of the size of partition even they are bigger than recommended because you just do not have any other option, but automatic denying might be configurable per table so if it occurs, that partition will be automatically denylisted. When it comes to logs, I think coding a custom slf4j appender is the most natural thing to implement. It is super easy. One caveat is that if we are selecting from that virtual table, the rows you get should be in reversed order. Basically, the newest log messages are last in the file but they should be first in the table because we can not expect people to "scroll down" to the end of cql output every time to see new messages. They should be at the very top. When it comes reading a file, we should then read it in a reversed order. Unfortunately, there is (1) which is able to do that and we depend on apache-commons already so we do not need to add any new dependency. The problem with this approach is - what should be the primary key? Parsing the timestamp from a line of log message seems to be error-prone because users might have different formatting of timestamps set in logger configuration (message format). My idea of doing this to use CircularFifoBuffer (2) - we again already depend on this library. The basic idea behind this is that buffer would have a constant size, e.g. 10k lines, messages would be added on top and if the buffer is full, the oldest message would be dropped so new one can be inserted. By doing this, we would have constant size of the vtable and the log messages would be "rolled up" automatically. With compressing the messages, I think the cost of having 10k of messages in memory is peanuts. Even 100k is just fine. What do you think [~rustyrazorblade]? [~brandon.williams] (1) https://commons.apache.org/proper/commons-io/javadocs/api-release/org/apache/commons/io/input/ReversedLinesFileReader.html (2) https://commons.apache.org/proper/commons-collections/javadocs/api-3.2.2/org/apache/commons/collections/buffer/CircularFifoBuffer.html > Get warning and errors through virtual tables > - > > Key: CASSANDRA-17948 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17948 > Project: Cassandra > Issue Type: New Feature >Reporter: Michiel Saelen >Priority: Normal > > The warnings and errors are currently only accessible through Cassandra logs. > Automating the monitoring of the nodes would be much easier/secure if we can > make use of virtual tables to get the logs. -- This message was sent by Atlassian 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 (15f33ca2 -> f4315820)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 15f33ca2 generate docs for 2af01b8f new f4315820 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 (15f33ca2) \ N -- N -- N refs/heads/asf-staging (f4315820) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740078 -> 4740078 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
