[jira] [Commented] (CASSANDRASC-91) AbstractHandler is handling the request even when it fails to extract params
[ https://issues.apache.org/jira/browse/CASSANDRASC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800915#comment-17800915 ] n.v.harikrishna commented on CASSANDRASC-91: Raised pr: [CASSANDRASC-91 Returning when AbstractHandler encounters exception while extracting params from the request. by nvharikrishna · Pull Request #88 · apache/cassandra-sidecar (github.com)|https://github.com/apache/cassandra-sidecar/pull/88] > AbstractHandler is handling the request even when it fails to extract params > > > Key: CASSANDRASC-91 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-91 > Project: Sidecar for Apache Cassandra > Issue Type: Bug >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Labels: pull-request-available > > AbstractHandler’s handle method is calling extractParamsOrThrow method to > parse the request which can fail with HttpException (a runtime exception). > When extraction fails, then AbstractHandler is processing the failure using > processFailure method and continued to call handleInternal method. Calling > handlerInternal even when failed to extract params resulting unwanted > results. If the extraction of parameters failes, then AbstractHandler should > not call handleInternal. > > Example: > Passing an invalid character for ring route per keysapce endpoint (handled by > RingHandler which is extending AbstractHandler) something like : > [localhost1:9043/api/v1/cassandra/ring/keyspaces/keysapce%60] is resulting to > _Bad Request_ response, but also resulting NPE from the > RingHandler.handleInternal method > > java.lang.NullPointerException: null > at > org.apache.cassandra.sidecar.routes.RingHandler.lambda$handleInternal$0(RingHandler.java:83) > at > io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180) > at > io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277) > at > io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199) > at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > > It should terminate processing the request when it could not parse the > keyspace. -- This message was sent by Atlassian Jira (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] (CASSANDRASC-91) AbstractHandler is handling the request even when it fails to extract params
[ https://issues.apache.org/jira/browse/CASSANDRASC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-91: -- Labels: pull-request-available (was: ) > AbstractHandler is handling the request even when it fails to extract params > > > Key: CASSANDRASC-91 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-91 > Project: Sidecar for Apache Cassandra > Issue Type: Bug >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Labels: pull-request-available > > AbstractHandler’s handle method is calling extractParamsOrThrow method to > parse the request which can fail with HttpException (a runtime exception). > When extraction fails, then AbstractHandler is processing the failure using > processFailure method and continued to call handleInternal method. Calling > handlerInternal even when failed to extract params resulting unwanted > results. If the extraction of parameters failes, then AbstractHandler should > not call handleInternal. > > Example: > Passing an invalid character for ring route per keysapce endpoint (handled by > RingHandler which is extending AbstractHandler) something like : > [localhost1:9043/api/v1/cassandra/ring/keyspaces/keysapce%60] is resulting to > _Bad Request_ response, but also resulting NPE from the > RingHandler.handleInternal method > > java.lang.NullPointerException: null > at > org.apache.cassandra.sidecar.routes.RingHandler.lambda$handleInternal$0(RingHandler.java:83) > at > io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180) > at > io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277) > at > io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199) > at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > at java.lang.Thread.run(Thread.java:748) > > It should terminate processing the request when it could not parse the > keyspace. -- This message was sent by Atlassian Jira (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-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800885#comment-17800885 ] Brad Schoening edited comment on CASSANDRA-19206 at 12/28/23 3:54 AM: -- [~gautamg] The newly released 3.29 driver removes the six dependency. See [PR 1172|[https://github.com/datastax/python-driver/pull/1172]]. Can you re-test with the 3.29 driver? was (Author: bschoeni): [~gautamg] The newly released 3.29 driver removes the six dependency. See [PR 1172|[https://github.com/datastax/python-driver/pull/1172].] Can you re-test with 3.29? > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800885#comment-17800885 ] Brad Schoening edited comment on CASSANDRA-19206 at 12/28/23 3:54 AM: -- [~gautamg] The newly released 3.29 driver removes the six dependency. See PR-1172: [https://github.com/datastax/python-driver/pull/1172]. Can you re-test with the 3.29 driver? was (Author: bschoeni): [~gautamg] The newly released 3.29 driver removes the six dependency. See [PR 1172|[https://github.com/datastax/python-driver/pull/1172]]. Can you re-test with the 3.29 driver? > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800885#comment-17800885 ] Brad Schoening edited comment on CASSANDRA-19206 at 12/28/23 3:52 AM: -- [~gautamg] The newly released 3.29 driver removes the six dependency. See [PR 1172|[https://github.com/datastax/python-driver/pull/1172].] Can you re-test with 3.29? was (Author: bschoeni): [~gautamg] The newly released 3.29 driver removes the six dependency. See [PR 1172 title|[https://github.com/datastax/python-driver/pull/1172].] Can you re-test with 3.29? > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800885#comment-17800885 ] Brad Schoening edited comment on CASSANDRA-19206 at 12/28/23 3:52 AM: -- [~gautamg] The newly released 3.29 driver removes the six dependency. See [PR 1172 title|[https://github.com/datastax/python-driver/pull/1172].] Can you re-test with 3.29? was (Author: bschoeni): The just released 3.29 driver removes the six dependency. See [PR 1172 title|[https://github.com/datastax/python-driver/pull/1172].] Can you re-test with 3.29? > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-91) AbstractHandler is handling the request even when it fails to extract params
n.v.harikrishna created CASSANDRASC-91: -- Summary: AbstractHandler is handling the request even when it fails to extract params Key: CASSANDRASC-91 URL: https://issues.apache.org/jira/browse/CASSANDRASC-91 Project: Sidecar for Apache Cassandra Issue Type: Bug Reporter: n.v.harikrishna Assignee: n.v.harikrishna AbstractHandler’s handle method is calling extractParamsOrThrow method to parse the request which can fail with HttpException (a runtime exception). When extraction fails, then AbstractHandler is processing the failure using processFailure method and continued to call handleInternal method. Calling handlerInternal even when failed to extract params resulting unwanted results. If the extraction of parameters failes, then AbstractHandler should not call handleInternal. Example: Passing an invalid character for ring route per keysapce endpoint (handled by RingHandler which is extending AbstractHandler) something like : [localhost1:9043/api/v1/cassandra/ring/keyspaces/keysapce%60] is resulting to _Bad Request_ response, but also resulting NPE from the RingHandler.handleInternal method java.lang.NullPointerException: null at org.apache.cassandra.sidecar.routes.RingHandler.lambda$handleInternal$0(RingHandler.java:83) at io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180) at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277) at io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199) at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748) It should terminate processing the request when it could not parse the keyspace. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19206) ./bin/cqlsh breaks with an python version 3.12.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800885#comment-17800885 ] Brad Schoening commented on CASSANDRA-19206: The just released 3.29 driver removes the six dependency. See [PR 1172 title|[https://github.com/datastax/python-driver/pull/1172].] Can you re-test with 3.29? > ./bin/cqlsh breaks with an python version 3.12.1 > > > Key: CASSANDRA-19206 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19206 > Project: Cassandra > Issue Type: Bug >Reporter: Gautam G >Priority: Normal > Attachments: image-2023-12-18-01-38-47-424.png, > image-2023-12-18-01-39-33-839.png, image-2023-12-18-01-40-38-974.png > > > Inside cassandra directory, on running ./bin/cqlsh gives ModuleNotFoundError > when run using python 3.12.1. > ./bin/cqlsh works well for python versions like 3.9.18. > > The below image shows the error that occured while using python 3.12.1 > !image-2023-12-18-01-39-33-839.png! > > The below image shows how it should normally work, it was ran on python 3.9.18 > !image-2023-12-18-01-40-38-974.png! > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800879#comment-17800879
]
Paulo Motta commented on CASSANDRA-19001:
-
Added [this
commit|https://github.com/pauloricardomg/cassandra/commit/cdc4124873f2b29c4d42e3265a9c7f408bcd98c4]
to
[pauloricardomg/19001-5.0-patch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:cassandra:19001-5.0-patch]
to fail "nodetool sjk" with a nicer message when a JDK is not found:
"nodetool sjk jps" output with JDK17:
{noformat}
$ bin/nodetool sjk jps
28270 org.apache.cassandra.tools.NodeTool -p 7199 sjk jps
{noformat}
"nodetool sjk jps" output with JRE17:
{noformat}
$ docker run --rm -it cassandra-test:5.0-19001 nodetool sjk jps | cat | head
-n10
ERROR: JDK not detected and nodetool sjk requires JDK to work.
{noformat}
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19001:
Reviewers: Paulo Motta, Paulo Motta
Paulo Motta, Paulo Motta (was: Paulo Motta)
Status: Review In Progress (was: Patch Available)
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19001:
Status: Changes Suggested (was: Review In Progress)
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19001:
Status: Patch Available (was: In Progress)
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-19001:
Status: Open (was: Patch Available)
> Check whether the startup warnings for unknown modules represent a legit
> problem or cosmetic issue
> --
>
> Key: CASSANDRA-19001
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19001
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> During the 5.0 alpha 2 release
> [vote|https://lists.apache.org/thread/lt3x0obr5cpbcydf5490pj6b2q0mz5zr],
> [~paulo] raised the following concerns:
> {code:java}
> Launched a tarball-based 5.0-alpha2 container on top of
> "eclipse-temurin:17-jre-focal" and the server starts up fine, can run
> nodetool and cqlsh.
> I got these seemingly harmless JDK17 warnings during startup and when
> running nodetool (no warnings on JDK11):
> WARNING: Unknown module: jdk.attach specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-exports
> WARNING: Unknown module: jdk.compiler specified to --add-opens
> WARNING: A terminally deprecated method in java.lang.System has been called
> WARNING: System::setSecurityManager has been called by
> org.apache.cassandra.security.ThreadAwareSecurityManager
> (file:/opt/cassandra/lib/apache-cassandra-5.0-alpha2-SNAPSHOT.jar)
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cassandra.security.ThreadAwareSecurityManager
> WARNING: System::setSecurityManager will be removed in a future release
> Anybody knows if these warnings are legit/expected ? We can create
> follow-up tickets if needed.
> $ java --version
> openjdk 17.0.9 2023-10-17
> OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
> OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode,
> sharing)
> {code}
> {code:java}
> Clarification: - When running nodetool only the "Unknown module" warnings
> show up. All warnings show up during startup.{code}
> We need to verify whether this presents a real problem in the features where
> those modules are expected to be used, or if it is a false alarm.
>
--
This message was sent by Atlassian Jira
(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-19001) Check whether the startup warnings for unknown modules represent a legit problem or cosmetic issue
[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800870#comment-17800870
]
Paulo Motta commented on CASSANDRA-19001:
-
I finally got a chance to take a look at this, apologies for the delay.
It looks like the [JDK detection
check|https://github.com/ekaterinadimitrova2/cassandra/blob/613bb6d2cbc40924479eac044f78e0c4e584521b/bin/cassandra.in.sh#L153]
does not work when the JRE is on {{/opt/java/openjdk/bin/java}} which is the
case for the official docker image. I updated the check [on this
commit|https://github.com/pauloricardomg/cassandra/commit/97472afcc4f63291ebbbcc6aab476b0ccf12ce06]
to check for the presence of the {{javac}} executable on the {{$PATH}} or
{{$JAVA_HOME}} to detect whether a JDK is present. Let me know what do you
think.
I checked that no more warnings "Unknown module: jdk.attach specified to
--add-exports" are logged during server initialization, nor when calling
nodetool commands when using JRE17:
*BEFORE:*
{noformat}
$ docker run --rm -it cassandra:5 nodetool help | cat | head -n10
WARNING: Unknown module: jdk.attach specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-exports
WARNING: Unknown module: jdk.compiler specified to --add-opens
usage: nodetool [(-p | --port )]
[(-u | --username )]
[(-pw | --password )]
[(-pwf | --password-file )]
[(-pp | --print-port)] [(-h | --host )] []
{noformat}
*AFTER:*
{noformat}
$ docker run --rm -it cassandra-test:5.0-19001 nodetool help | cat | head -n10
usage: nodetool [(-pw | --password )]
[(-p | --port )]
[(-pwf | --password-file )]
[(-pp | --print-port)] [(-h | --host )]
[(-u | --username )] []
{noformat}
I also checked that nodetool sjk fails with this message on JRE17:
{noformat}
$ docker run --rm -it cassandra-test:5.0-19001 nodetool sjk jps | head -n10
ERROR 17:22:29,631 Java home points to /opt/java/openjdk make sure it is not a
JRE path
ERROR 17:22:29,632 Failed to add tools.jar to classpath
java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown
Source)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown
Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at org.gridkit.lab.jvm.attach.AttachAPI.(AttachAPI.java:52)
{noformat}
But works when a JDK17 is present:
{noformat}
$ bin/nodetool sjk jps
22825 org.apache.cassandra.tools.NodeTool -p 7199 sjk jps
{noformat}
I checked that all commands above have the same output on JRE11.
I briefly tested the full query logger on a JRE17 with the patch above and it
seems to be working:
{noformat}
root@6c9f22a89594:/# nodetool enablefullquerylog --path /tmp/bla
root@6c9f22a89594:/# cqlsh
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.0-beta1-SNAPSHOT | CQL spec 3.4.7 | Native protocol
v5]
Use HELP for help.
cqlsh> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> exit
root@6c9f22a89594:/# /opt/cassandra/tools/bin/fqltool dump /tmp/bla
INFO [main] 2023-12-27 16:56:34,673 DatabaseDescriptor.java:1557 - Supported
sstable formats are: big ->
org.apache.cassandra.io.sstable.format.big.BigFormat with singleton components:
[Data.db, Index.db, Statistics.db, CompressionInfo.db, Filter.db, Summary.db,
Digest.crc32, CRC.db, TOC.txt], bti ->
org.apache.cassandra.io.sstable.format.bti.BtiFormat with singleton components:
[Data.db, Partitions.db, Rows.db, Statistics.db, CompressionInfo.db, Filter.db,
Digest.crc32, CRC.db, TOC.txt]
INFO [main] 2023-12-27 16:56:34,723 Jvm.java:174 - Chronicle core loaded from
file:/opt/cassandra/lib/chronicle-core-2.23.36.jar
INFO [main] 2023-12-27 16:56:34,817 Slf4jExceptionHandler.java:44 - Took 6 ms
to add mapping for /tmp/bla/metadata.cq4t
INFO [main] 2023-12-27 16:56:34,859 Slf4jExceptionHandler.java:44 - Running
under OpenJDK Runtime Environment 17.0.9+9 with 16 processors reported.
INFO [main] 2023-12-27 16:56:34,860 Slf4jExceptionHandler.java:44 - Leave your
e-mail to get information about the latest releases and patches at
https://chronicle.software/release-notes/
INFO [main] 2023-12-27 16:56:34,861 Slf4jExceptionHandler.java:44 - Process
id: 1015 :: Chronicle Queue (5.23.37)
Type: single-query
Query start time: 1703696157539
Protocol version: 5
Generated timestamp:-9223372036854775808
Generated nowInSeconds:1703696157
Query: SELECT * FROM system.peers_v2
Values:
Type: single-query
Query start time: 1703696157544
Protocol version: 5
Generated timestamp:-9223372036854775808
Generated nowInSeconds:1703696157
Query: SELECT * FROM system.local WHERE key='local'
Values:
{noformat}
I inspected chronicle queue code and documentation and I think that a JDK is
only required
[jira] [Commented] (CASSANDRA-19241) Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3
[ https://issues.apache.org/jira/browse/CASSANDRA-19241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800847#comment-17800847 ] Chris Lambertus commented on CASSANDRA-19241: - The updated nodes need to take into account splitting docker's home and /home/jenkins so they do not share the same filesystem namespace, and have adequate space allocated for both. > Upgrade ci-cassandra.a.o agents to Ubuntu 22.04.3 > - > > Key: CASSANDRA-19241 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19241 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > All agents are currently Ubuntu 18.04 LTS per the > [docs|https://github.com/apache/cassandra-builds/blob/trunk/ASF-jenkins-agents.md#server-requirements]. > All agents need to be upgraded to Ubuntu 22.04.3 LTS. -- This message was sent by Atlassian Jira (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-14867) Histogram overflows potentially leading to writes failing
[
https://issues.apache.org/jira/browse/CASSANDRA-14867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14867:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Fix Version/s: 5.x
Since Version: 3.11.1
> Histogram overflows potentially leading to writes failing
> -
>
> Key: CASSANDRA-14867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14867
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
> Environment: cassandra 3.11.1 on ubuntu 16.04
>Reporter: David
>Priority: Normal
> Fix For: 5.x
>
>
> I observed the following in cassandra logs on 1 host of a 6-node cluster:
> {code}
> ERROR [ScheduledTasks:1] 2018-11-01 17:26:41,277 CassandraDaemon.java:228 -
> Exception in thread Thread[ScheduledTasks:1,5,main]
> java.lang.IllegalStateException: Unable to compute when histogram overflowed
> at
> org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir$EstimatedHistogramReservoirSnapshot.getMean(DecayingEstimatedHistogramReservoir.java:472)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService.getDroppedMessagesLogs(MessagingService.java:1263)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService.logDroppedMessages(MessagingService.java:1236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService.access$200(MessagingService.java:87)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService$4.run(MessagingService.java:507)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_172]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_172]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_172]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_172]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [na:1.8.0_172]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_172]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_172]
> {code}
> At the same time, this node was failing all writes issued to it. Restarting
> cassandra on the node brought the cluster into a good state and we stopped
> seeing the histogram overflow errors.
> Has this issue been observed before? Could the histogram overflows cause
> writes to fail?
--
This message was sent by Atlassian Jira
(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-19082) Histogram overflow causes client timeouts and message drops
[
https://issues.apache.org/jira/browse/CASSANDRA-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19082:
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
Closing this issue as it's being duplicated by CASSANDRA-14867
Feel free to reopen the issue if you think the cause is different.
> Histogram overflow causes client timeouts and message drops
> ---
>
> Key: CASSANDRA-19082
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19082
> Project: Cassandra
> Issue Type: Bug
>Reporter: Zbyszek Z
>Priority: Normal
>
> Hi,
> We have recently noticed that sometimes this exception happens on our
> Cassandra cluster:
> {code:java}
> ERROR [ScheduledTasks:1] 2023-11-24 06:24:12,680 CassandraDaemon.java:244 -
> Exception in thread Thread[ScheduledTasks:1,5,main]
> java.lang.IllegalStateException: Unable to compute when histogram overflowed
> at
> org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir$EstimatedHistogramReservoirSnapshot.getMean(DecayingEstimatedHistogramReservoir.java:472)
> at
> org.apache.cassandra.net.MessagingService.getDroppedMessagesLogs(MessagingService.java:1272)
> at
> org.apache.cassandra.net.MessagingService.logDroppedMessages(MessagingService.java:1244)
> at
> org.apache.cassandra.net.MessagingService.access$200(MessagingService.java:84)
> at
> org.apache.cassandra.net.MessagingService$4.run(MessagingService.java:512)
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750)
> {code}
> It happens on all 6 nodes at the same time. Also we see increased client
> timeouts and dropped READ and READ_RESPONSE messages. Our Cassandra is
> 3.11.16, 2 DC setup, 6 node in each DC. RF is 3. I have searched issues but
> could not find exactly same issue causing messages to be dropped. Any
> suggestion would be appreciated.
--
This message was sent by Atlassian Jira
(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-19105) Using Capture to save results in CQLSH with Tracing on incorrectly saves the trace details
[
https://issues.apache.org/jira/browse/CASSANDRA-19105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800807#comment-17800807
]
Gautam G edited comment on CASSANDRA-19105 at 12/27/23 3:07 PM:
I would like to work on this issue, can I get some suggestions on what source
files to look for etc., I can find there is a folder for Tracing in
src/Services.
Thank you
was (Author: gautamg):
I would like to work on this issue, can I get some suggestions on what file to
look for etc.
Thank you
> Using Capture to save results in CQLSH with Tracing on incorrectly saves the
> trace details
> --
>
> Key: CASSANDRA-19105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19105
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Priority: Normal
>
> When using *Tracing* in CQLSH, it's sometimes helpful to use *Capture* to
> avoid paging through output when you want to see the trace results. However,
> the trace results are also incorrectly captured to the output file.
> According to *Help Capture* (below), only the query result should be saved.
> The correct behavior should display the trace results and only capture the
> query results.
> {_}Help capture message{_}: Only query result output is captured.
> Errors and output from cqlsh-only commands will still be shown in the cqlsh
> session.
>
--
This message was sent by Atlassian Jira
(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-19242) Update cqlsh and driver versions in 5.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19242: --- Description: The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on trunk (5.1) to 6.3.0. The DataStax Python driver 3.28 requires python 3.8+, so python version requirements in bin/cqlsh, bin/cqlsh.py, README.asc etc should be updated to match. was: The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on trunk (5.1) to 6.3.0. The DataStax Python driver supports python 3.8+, so python version requirements in bin/cqlsh.py should be updated to match. > Update cqlsh and driver versions in 5.x > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. > The DataStax Python driver 3.28 requires python 3.8+, so python version > requirements in bin/cqlsh, bin/cqlsh.py, README.asc etc should be updated to > match. -- This message was sent by Atlassian Jira (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-19242) Update cqlsh and driver versions in 5.x
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19242: --- Summary: Update cqlsh and driver versions in 5.x (was: Update cqlsh version in 5.1) > Update cqlsh and driver versions in 5.x > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19242) Update cqlsh version in 5.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening reassigned CASSANDRA-19242: -- Assignee: Brad Schoening > Update cqlsh version in 5.1 > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19242) Update cqlsh version in 5.1
[ https://issues.apache.org/jira/browse/CASSANDRA-19242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-19242: --- Change Category: Semantic Complexity: Low Hanging Fruit Component/s: CQL/Interpreter Status: Open (was: Triage Needed) > Update cqlsh version in 5.1 > --- > > Key: CASSANDRA-19242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > > The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on > trunk (5.1) to 6.3.0. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19242) Update cqlsh version in 5.1
Brad Schoening created CASSANDRA-19242: -- Summary: Update cqlsh version in 5.1 Key: CASSANDRA-19242 URL: https://issues.apache.org/jira/browse/CASSANDRA-19242 Project: Cassandra Issue Type: Task Reporter: Brad Schoening The cqlsh in version 5.0 is 6.2.0, so the version should be incremented on trunk (5.1) to 6.3.0. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch asf-staging updated (eef7824a6 -> fdaba11f5)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit eef7824a6 generate docs for 13ca47fe add 37300befe Change Summit's register button to watch videos new fdaba11f5 generate docs for 37300bef 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 (eef7824a6) \ N -- N -- N refs/heads/asf-staging (fdaba11f5) 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/_/index.html | 4 +- .../4.1.0/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.0/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1.1/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.1/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1.2/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.2/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1.3/cassandra/tools/nodetool/bootstrap.html | 7 +- .../4.1.3/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../4.1/cassandra/tools/nodetool/bootstrap.html| 7 +- .../doc/4.1/cassandra/tools/nodetool/nodetool.html | 7 +- .../4.1/cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../managing/tools/nodetool/bootstrap.html | 9 ++- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 80 ++--- .../getting-started/mtlsauthenticators.html| 69 ++ .../managing/configuration/cass_yaml_file.html | 3 + .../managing/tools/nodetool/bootstrap.html | 8 +-- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 68 +- .../managing/tools/nodetool/bootstrap.html | 9 ++- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 80 ++--- .../stable/cassandra/tools/nodetool/bootstrap.html | 7 +- .../stable/cassandra/tools/nodetool/nodetool.html | 7 +- .../cassandra/tools/nodetool/repair_admin.html | 80 +++-- .../getting-started/mtlsauthenticators.html| 69 ++ .../managing/configuration/cass_yaml_file.html | 3 + .../managing/tools/nodetool/bootstrap.html | 8 +-- .../managing/tools/nodetool/nodetool.html | 10 +-- .../managing/tools/nodetool/repair_admin.html | 68 +- content/search-index.js| 2 +- site-content/source/modules/ROOT/pages/index.adoc | 4 +- site-ui/build/ui-bundle.zip| Bin 4883726 -> 4883726 bytes 38 files changed, 629 insertions(+), 459 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-website) branch trunk updated: Change Summit's register button to watch videos
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 37300befe Change Summit's register button to watch videos 37300befe is described below commit 37300befeb54cdb3e0fffdfa8e28a8c7ed03fe1b Author: mck AuthorDate: Wed Dec 27 13:56:39 2023 +0100 Change Summit's register button to watch videos --- site-content/source/modules/ROOT/pages/index.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/index.adoc b/site-content/source/modules/ROOT/pages/index.adoc index b601fa8e7..8e575f472 100644 --- a/site-content/source/modules/ROOT/pages/index.adoc +++ b/site-content/source/modules/ROOT/pages/index.adoc @@ -44,10 +44,10 @@ Banner: The section below is where the updated banner content goes. [discrete] image:events/cassandra-summit-banner-1000x250.png[Cassandra Summit 2023] [discrete] -=== Let's celebrate what we've built and share what's next! +=== Talks and Keynotes videos are published! [.btn.btn--grad] -https://events.linuxfoundation.org/cassandra-summit/register/[Register now^] +https://events.linuxfoundation.org/cassandra-summit/program/schedule/[Watch the videos^] -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800737#comment-17800737 ] Claude Warren commented on CASSANDRA-16565: --- [https://github.com/apache/cassandra/pull/2842] contains the latest code and should be the basis for any reviews at this point. Thanks to [~smiklosovic] for helping to drive this forward. > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
