[
https://issues.apache.org/jira/browse/CASSANDRA-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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> | --port <port>)]
[(-u <username> | --username <username>)]
[(-pw <password> | --password <password>)]
[(-pwf <passwordFilePath> | --password-file <passwordFilePath>)]
[(-pp | --print-port)] [(-h <host> | --host <host>)] <command> [<args>]
{noformat}
*AFTER:*
{noformat}
$ docker run --rm -it cassandra-test:5.0-19001 nodetool help | cat | head -n10
usage: nodetool [(-pw <password> | --password <password>)]
[(-p <port> | --port <port>)]
[(-pwf <passwordFilePath> | --password-file <passwordFilePath>)]
[(-pp | --print-port)] [(-h <host> | --host <host>)]
[(-u <username> | --username <username>)] <command> [<args>]
{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.<clinit>(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 when the [high level
interface|https://github.com/OpenHFT/Chronicle-Queue?tab=readme-ov-file#high-level-interface-for-readingwriting]
is used since it requires [dynamic JVM compilation to create object
stubs|https://github.com/OpenHFT/Chronicle-Wire?tab=readme-ov-file#spring-boot-and-dynamic-compilation-in-chronicle-wire].
This seems to be corroborated by [this
comment|https://github.com/OpenHFT/Chronicle-Queue/issues/909#issuecomment-924626439]
which indicates the jdk compiler modules are not required by chronicle queue,
despite the [chronicle documentation saying
otherwise|https://chronicle.software/chronicle-support-java-17/]. From a quick
code inspection it doesn't look like we're using this high level API
(MethodWriter/MethodReader) in our chronicle queue usage so I don't think a JDK
is required in our case. Tagging [~aweisberg] and [~stefan.miklosovic] which
may be familiar with the FQL machinery to confirm.
I would prefer not to dis-recommend the use of JRE for FQL/Audit Logging unless
we have evidence that it does not work via a unit test or user report so I
created [this
commit|https://github.com/pauloricardomg/cassandra/commit/33477b20edd045d8449b8ab0991adbb92e4af6fb]
to remove this recommendation from the documentation and cassandra.yaml.
If it's confirmed that FQL/Audit Log does not require JDK to function properly,
then SJK will be the only known functionality to explicitly require an SDK to
work. Given this is an optional command for operator troubleshooting, I don't
think we should require the use of a JDK to run Cassandra unless there are
relevant/core features that require it.
Let me know what do you think.
> 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
