[
https://issues.apache.org/jira/browse/CASSANDRA-15468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010070#comment-17010070
]
Gus Heck edited comment on CASSANDRA-15468 at 1/7/20 8:35 PM:
--------------------------------------------------------------
I'd like to respectfully ask that this not be resolved yet. I don't agree that
there are no problems here. What is the point of the latter half of the
message?
{quote}Some data, both in-memory and on-disk, may live longer due to garbage
collection.{quote}
I would say that's quite incorrect since Cassandra won't even be starting up,
and even if it did attempts to use FileUtils.clean() are going to throw NPE's
which will probably do a bit worse than cause data to live longer.
Additionally the message give here is cryptic and leaves the user unable to
discern (without searching through your jira, and taking the time to fully
debug cassandra's code, and read your startups scripts as I did) what the
problem is or how to correct it. So before we close this I'd like to suggest
one thing that I hope is non-controversial, and another that might require some
consideration:
1. Revise the error message here for the case of an IllegalAccessException to
advise the user how to move forward. Particularly tell them that they should
either use the standard cassandra start up scripts, or (expert) supply the
following --add-export and --add-open jvm args
2. Perhaps document the exports and opens requirements in a machine readable
way by adding Add-Exports: and Add-Opens: attributes to the manifest for the
jar file.
Suggestion #2 will not change the need for the .options files unless a bigger
change to invoke via java -jar happens (which I'm not suggesting here, but it
could eliminate that portion of the options file)
At some point I'll likely add support to Uno-Jar to dig through manifests of
dependency jars looking for any jars with exports to collect them for the uber
jar... obviously that can only be a best effort thing, since no spec requires
such attributes but certainly it makes sense for jars to politely declare what
exports they require. (except of course proprietary stuff that might seek to
obfuscate and inhibit any usage not licensed...)
was (Author: gus_heck):
I'd like to respectfully ask that this not be resolved yet. I don't agree that
there are no problems here. What is the point of the latter half of the
message?
{quote}Some data, both in-memory and on-disk, may live longer due to garbage
collection.{quote}
I would say that's quite incorrect since Cassandra won't even be starting up,
and even if it did attempts to use FileUtils.clean() are going to throw NPE's
which will probably do a bit worse than cause data to live longer.
Additionally the message give here is cryptic and leaves the user unable to
discern (without searching through your jira, and taking the time to fully
debug cassandra's code, and read your startups scripts as I did) what the
problem is or how to correct it. So before we close this I'd like to suggest
one thing that I hope is non-controversial, and another that might require some
consideration:
1. Revise the error message here for the case of an IllegalAccessException to
advise the user how to move forward. Particularly tell them that they should
either use the standard cassandra start up scripts, or (expert) supply the
following --add-export and --add-open jvm args
2. Perhaps document the exports and opens requirements in a machine readable
way by adding Add-Exports: and Add-Opens: attributes to the manifest for the
jar file.
Suggestion #2 will not change the need for the .options files unless a bigger
change to invoke via java -jar happens (which I'm not suggesting here, but it
could eliminate that portion of the options file)
At some point I'll likely add support to Uno-Jar I'll to dig through manifests
of dependency jars looking for any jars with exports to collect them for the
uber jar... obviously that can only be a best effort thing, since no spec
requires such attributes but certainly it makes sense for jars to politely
declare what exports they require. (except of course proprietary stuff that
might seek to obfuscate and inhibit any usage not licensed...)
> Unable to start embedded cassandra on JDK 11
> --------------------------------------------
>
> Key: CASSANDRA-15468
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15468
> Project: Cassandra
> Issue Type: Bug
> Reporter: Gus Heck
> Priority: Normal
> Attachments: CASSANDRA-15468.patch
>
>
> Cassandra fails to start without the following jvm options from
> jvm-11-server.options:
> {code:java}
> -Djdk.attach.allowAttachSelf=true
> --add-exports java.base/jdk.internal.misc=ALL-UNNAMED
> --add-exports java.base/jdk.internal.ref=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.management.rmi/com.sun.jmx.remote.internal.rmi=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.registry=ALL-UNNAMED
> --add-exports java.rmi/sun.rmi.server=ALL-UNNAMED
> --add-exports java.sql/java.sql=ALL-UNNAMED
> --add-opens java.base/java.lang.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.loader=ALL-UNNAMED
> --add-opens java.base/jdk.internal.ref=ALL-UNNAMED
> --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED
> --add-opens java.base/jdk.internal.math=ALL-UNNAMED
> --add-opens java.base/jdk.internal.module=ALL-UNNAMED
> --add-opens java.base/jdk.internal.util.jar=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> {code}
> Without these options the following stack trace appears and prevents startup
> {code:java}
> 2020-01-05T17:42:15,009 ERROR main
> org.apache.cassandra.service.CassandraDaemon Exception encountered during
> startup java.lang.ExceptionInInitializerError
> at
> org.apache.cassandra.config.DatabaseDescriptor.guessFileStore(DatabaseDescriptor.java:1127)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:541)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:340)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:168)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:152)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:665)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:609)
> at org.jesterj.ingest.persistence.Cassandra.start(Cassandra.java:135)
> at
> org.jesterj.ingest.scanners.SimpleFileScannerImplFTITest.testScanWithMemory(SimpleFileScannerImplFTITest.java:63)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: java.lang.IllegalAccessException:
> access to public member failed:
> jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@779dfe55/invokeVirtual,
> from org.apache.cassandra.io.util.FileUtils (unnamed module @2eda0940)
> at org.apache.cassandra.io.util.FileUtils.<clinit>(FileUtils.java:95)
> ... 33 more
> Caused by: java.lang.IllegalAccessException: access to public member failed:
> jdk.internal.ref.Cleaner.clean[Ljava.lang.Object;@779dfe55/invokeVirtual,
> from org.apache.cassandra.io.util.FileUtils (unnamed module @2eda0940)
> at
> java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:942)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:2206)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.checkMethod(MethodHandles.java:2146)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:2290)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:2283)
> at
> java.base/java.lang.invoke.MethodHandles$Lookup.unreflect(MethodHandles.java:1747)
> at org.apache.cassandra.io.util.FileUtils.<clinit>(FileUtils.java:86)
> ... 33 more
> {code}
> Use of --add-exports is described in the oracle documentation as
> {quote}You may use the --add-exports option as a temporary workaround to
> compile source code with references to JDK internal classes.
> {quote}
> which implies that this will not work forever. Also the code in FileUtils
> seems somewhat confused as it prints out a warning, as if it means to allow
> startup with a lower performance expectation, and then throws an exception
> that entirely prevents startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
