I am using Windows 10 and I have installed Cassandra 3.9.0 and my updated JDK version is java version "1.8.0_211"
When I run the command cassandra -f
it stops giving me this error:
Exception (java.lang.AbstractMethodError) encountered during startup: org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
java.lang.AbstractMethodError: org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
at javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150)
at javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405)
at org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106)
at org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:145)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:219)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730)
ERROR 12:54:22 Exception encountered during startup
java.lang.AbstractMethodError: org.apache.cassandra.utils.JMXServerUtils$Exporter.exportObject(Ljava/rmi/Remote;ILjava/rmi/server/RMIClientSocketFactory;Ljava/rmi/server/RMIServerSocketFactory;Lsun/misc/ObjectInputFilter;)Ljava/rmi/Remote;
at javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:150) ~[na:1.8.0_161]
at javax.management.remote.rmi.RMIJRMPServerImpl.export(RMIJRMPServerImpl.java:135) ~[na:1.8.0_161]
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:405) ~[na:1.8.0_161]
at org.apache.cassandra.utils.JMXServerUtils.createJMXServer(JMXServerUtils.java:106) ~[apache-cassandra-3.9.0.jar:3.9.0]
at org.apache.cassandra.service.CassandraDaemon.maybeInitJmx(CassandraDaemon.java:145) [apache-cassandra-3.9.0.jar:3.9.0]
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:219) [apache-cassandra-3.9.0.jar:3.9.0]
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:601) [apache-cassandra-3.9.0.jar:3.9.0]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:730) [apache-cassandra-3.9.0.jar:3.9.0]
I have gone through many posts but none of them solves my problem. Please suggest. and let me know if more information is required.
see: https://issues.apache.org/jira/browse/CASSANDRA-14173
org.apache.cassandra.utils.JMXServerUtils which is used to
programatically configure the JMX server and RMI registry
(CASSANDRA-2967, CASSANDRA-10091) depends on some JDK internal
classes/interfaces. A change to one of these, introduced in Oracle JDK
1.8.0_162 is incompatible, which means we cannot build using that JDK version. Upgrading the JVM on a node running 3.6+ will result in
Cassandra being unable to start.
Upgrade to newer version of Cassandra (3.11.4 to date) or downgrade jdk first and the problem will be resolved
Related
When Tomcat loads my war, I get this error:
Exception in thread "ClientMessageReceptor0" java.lang.NoClassDefFoundError: java/net/Inet6Address
at org.jacorb.orb.iiop.IIOPAddress.getNetworkInetAddresses(IIOPAddress.java:675)
at org.jacorb.orb.iiop.IIOPAddress.getLocalHost(IIOPAddress.java:591)
at org.jacorb.orb.iiop.IIOPAddress.getLocalHostAddress(IIOPAddress.java:574)
at org.jacorb.orb.listener.SSLListenerUtil.processException(SSLListenerUtil.java:73)
at org.jacorb.orb.iiop.IIOPConnection.handleCommFailure(IIOPConnection.java:77)
at org.jacorb.orb.etf.StreamConnectionBase.read(StreamConnectionBase.java:139)
at org.jacorb.orb.giop.GIOPConnection.getMessage(GIOPConnection.java:389)
at org.jacorb.orb.giop.GIOPConnection.receiveMessagesLoop(GIOPConnection.java:541)
at org.jacorb.orb.giop.GIOPConnection.receiveMessages(GIOPConnection.java:533)
at org.jacorb.orb.giop.MessageReceptor.doWork(MessageReceptor.java:69)
at org.jacorb.util.threadpool.ConsumerTie.run(ConsumerTie.java:60)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: Illegal access: this web application instance has been stopped already. Could not load [java.net.Inet6Address]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1375)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1226)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1188)
Our application uses Tomcat v9.0.41 and JDK 1.8.0_111 . This same combination works for others in my team and also it worked for me sometime back. I'm not sure what changed now. I have looked at other similar posts and they suggest mismatch between Tomcat and JDK version. But above combination of Tomcat and JDK works for others.
I have removed all other JDK and JRE version on my system.
Ensured JAVA_HOME points to JDK 1.8.0_111 and PATH points to correct JRE.
Any pointers on how to debug this further? Can I turn on some logging during Tomcat startup to see what paths are being used by Tomcat? Any suggestions are highly appreciated :).
Since the update to Eclipse Tamurin JDK 11.0.15+10 we notice a problem as soon a HTTP request reaches Wildfly 20.0.1.Final. The same behaviour exsists in Wildfly 26.1.0.Final This only happens with the JDK Windows version, the Linux JDK works fine.
As it is an "Invalid file path" error, an OS dependent BUG seems possible.
Until now SAP Machine is the only JDK that does not encounter this failure.
I'm still not sure if this is a JDK or a Wildfly problem...
You can check that when opening the Wildfly Management Interface.
ERROR [io.undertow.request] (External Management Request Threads -- 1) UT005071: Undertow request failed HttpServerExchange{ GET /management}: java.io.IOError: java.io.FileNotFoundException: Invalid file path
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1103)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1093)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels.<clinit>(Channels.java:1093)
at io.undertow.core#2.1.3.Final//io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:231)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:245)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:238)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:75)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:107)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainUtil.writeResponse(DomainUtil.java:89)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler$1.doSendResponse(DomainApiHandler.java:177)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.ResponseCallback.sendResponse(ResponseCallback.java:32)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:232)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:91)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:328)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:285)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at io.undertow.core#2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.core#2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:829)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.io.FileNotFoundException: Invalid file path
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:231)
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:126)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1098)
... 29 more
JDK
Works with Wildfly
Eclipse Tamurin
no
Amazon Coretto
no
Azul Zulu
no
Bellsoft
no
Oracle OpenJDK
no
Oracle JDK
no
SAP Machine
yes
This is an issue in the JDK. You can wait for JDK 11.0.16 or downgrade to a lower version like JDK 11.0.14.
This is caused by a known JDK bug. You can work around the issue by setting Djdk.io.File.enableADS system property. In Intellij go to Run -> Edit configurations and paste -Djdk.io.File.enableADS=true in VM Options field.
We are using this library to do 'docker pull' from docker hub and to check whether an image with a given name already exists. We need this to work in Linux, Mac and Windows having the latest version of docker installed. But in several cases, we have hit the error mentioned in the title and that error is coming from jersey-client that is internally used by this library.
We have tested using docker-java 3.1.5 and the latest 3.2.5 and on docker 19.03.5 and also the latest docker. The latest docker version varies on different platforms as mentioned below:
Linux (19.03.12)
Mac (19.03.8)
Windows (19.03.8)
Attached result of our tests
I am sharing a code snippet of what we are trying:
DockerClient dockerClient;
dockerClient = DockerClientBuilder.getInstance().build();
String imageName = "SOME_IMAGE_NAME";
List images = dockerClient.listImagesCmd().withImageNameFilter(imageName).exec();
if(!images.isEmpty()){
dockerClient.removeImageCmd(images.get(0).getId());
}
dockerClient.pullImageCmd(imageName).exec(new PullImageResultCallback()).awaitCompletion(DOCKER_PULL_WAIT_TIME, TimeUnit.SECONDS);
We are using Java 8.
If anyone has faced this kind of an issue before and solved it, can you please suggest how we should approach this problem?
Sharing the stacktrace:
java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
2020-07-13 22:14:59,255 ERROR [docker-java-stream--1445483847] ResultCallbackTemplate - Error during callback
java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:122) ~[jsr311-api-1.1.1.jar:?]
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:91) ~[jsr311-api-1.1.1.jar:?]
at javax.ws.rs.core.UriBuilder.newInstance(UriBuilder.java:69) ~[jsr311-api-1.1.1.jar:2.1.6]
at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:80) ~[jsr311-api-1.1.1.jar:2.1.6]
at javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:99) ~[jsr311-api-1.1.1.jar:2.1.6]
at org.glassfish.jersey.client.JerseyWebTarget.<init>(JerseyWebTarget.java:48) ~[jersey-client-2.30.1.jar:?]
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:274) ~[jersey-client-2.30.1.jar:?]
at org.glassfish.jersey.client.JerseyClient.target(JerseyClient.java:56) ~[jersey-client-2.30.1.jar:?]
at com.github.dockerjava.jaxrs.JerseyDockerHttpClient.execute(JerseyDockerHttpClient.java:291) ~[docker-java-transport-jersey-3.2.5.jar:?]
at com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:228) ~[docker-java-core-3.2.5.jar:?]
at com.github.dockerjava.core.DefaultInvocationBuilder.lambda$executeAndStream$1(DefaultInvocationBuilder.java:269) ~[docker-java-core-3.2.5.jar:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Caused by: java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1358) ~[catalina.jar:8.5.57]
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1180) ~[catalina.jar:8.5.57]
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_252]
at java.lang.Class.forName(Class.java:264) ~[?:1.8.0_252]
at javax.ws.rs.ext.FactoryFinder.newInstance(FactoryFinder.java:62) ~[jsr311-api-1.1.1.jar:?]
at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:155) ~[jsr311-api-1.1.1.jar:?]
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:105) ~[jsr311-api-1.1.1.jar:?]
... 11 more
The default transport that is used by docker-java library is jersey-client which has issues on non-Unix platforms. For that I had to explicitly use a different transport. I used Apache httpclient 5 which is anyway planned to be made default in the future releases of docker-java.
A list of transports for docker-java can be found at https://github.com/docker-java/docker-java/blob/master/docs/transports.md .
Recently I moved from the Oracle JDK 8 to Open JDK 8 (version: openjdk-1.8.0.242.b08) for Cloudera. Cloudera version is 5.16.2. I have Kerberos and TLS enabled. When I am using Oracle JDK the below issue doesn't occur but when I switch to Open JDK then I am getting the below error. Please note that the proxy user is already enabled from the CM -> HDFS -> configuration.
JobHistoryServer
Error starting JobHistoryServer
org.apache.hadoop.yarn.exceptions.YarnRuntimeException: Error creating done directory: [hdfs://XXXX.YYY.COM:8020/user/history/done]
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.tryCreatingHistoryDirs(HistoryFileManager.java:680)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.createHistoryDirs(HistoryFileManager.java:616)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.serviceInit(HistoryFileManager.java:577)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.mapreduce.v2.hs.JobHistory.serviceInit(JobHistory.java:95)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.service.CompositeService.serviceInit(CompositeService.java:107)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.serviceInit(JobHistoryServer.java:154)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.launchJobHistoryServer(JobHistoryServer.java:229)
at org.apache.hadoop.mapreduce.v2.hs.JobHistoryServer.main(JobHistoryServer.java:239)
Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.authorize.AuthorizationException): User: RZgWaGioVf#YYY.COM is not allowed to impersonate mapred/XXXX.YYY.COM#YYY.COM
at org.apache.hadoop.ipc.Client.call(Client.java:1504)
at org.apache.hadoop.ipc.Client.call(Client.java:1441)
at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:231)
at com.sun.proxy.$Proxy16.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:788)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:258)
at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
at com.sun.proxy.$Proxy17.getFileInfo(Unknown Source)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:2168)
at org.apache.hadoop.fs.Hdfs.getFileStatus(Hdfs.java:133)
at org.apache.hadoop.fs.FileContext$14.next(FileContext.java:1143)
at org.apache.hadoop.fs.FileContext$14.next(FileContext.java:1139)
at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
at org.apache.hadoop.fs.FileContext.getFileStatus(FileContext.java:1139)
at org.apache.hadoop.fs.FileContext$Util.exists(FileContext.java:1604)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.mkdir(HistoryFileManager.java:733)
at org.apache.hadoop.mapreduce.v2.hs.HistoryFileManager.tryCreatingHistoryDirs(HistoryFileManager.java:663)
This is a known bug I filed with openJDK.
"KerberosTicket client name refers wrongly to sAMAccountName in AD", Major loss of Function.
It is tracked here: https://bugs.openjdk.java.net/browse/JDK-8239385
This issue is resolved. The issue was due to the cross-realm referrals support for Kerberos (JDK-8215032). You need to set -Dsun.security.krb5.disableReferrals=true property of the service or to set this is java.security file.
Might be related to my problem: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1861883
I also reported this to the OpenJDK bug report site (twice) but no reaction so far.
If your problem disappears after downgrading to OpenJDK 1.8.0 232 we've been hit by the same bug.
The Problem
I'm trying to connect to a Apache Ignite server with Apache Ignite built-in tool, SQLLine. I get the error: java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
Background
I have Apache Ignite running in a container and CentOS7 running in another container. Both containers running in the same network (pinging works both ways). The tried connection is happening from CentOS7 to Apache Ignite.
Apache Ignite seems to be running fine with just the default configuration. In the CentOS7 container, I have installed Oracle JDK 12.0.1 and I have Apache Ignite 2.7.0 binary files in a folder. I have also set the IGNITE_HOME environmental variable.
Here, (https://apacheignite-sql.readme.io/docs/sqlline), it says I can connect to my cluster with just: ./sqlline.sh --verbose=true -u jdbc:ignite:thin://127.0.0.1/. However, this throws the previously mentioned error.
SQLLine should come with Ignite JDBC drivers. I have tried downloading them manually (https://apacheignite-sql.readme.io/docs/jdbc-driver#section-multiple-endpoints). When I downloaded the driver, which is said to be the ignite-core-{version}.jar, I put it in the same folder as sqlline.jar files.
Output
[root#bc72c4fbf47e bin]# ./sqlline.sh
sqlline version 1.3.0
sqlline> !connect jdbc:ignite:thin://172.19.0.2/
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:/var/tmp/apache-ignite/libs/ignite-core-2.7.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:415)
at java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:547)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:449)
at java.sql/java.sql.DriverManager.getDrivers(DriverManager.java:426)
at sqlline.SqlLine.findRegisteredDriver(SqlLine.java:1568)
at sqlline.SqlLine.scanForDriver(SqlLine.java:1542)
at sqlline.Commands.connect(Commands.java:1074)
at sqlline.Commands.connect(Commands.java:1001)
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:567)
at sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
Conclusion
I should be able to connect to my Ignite server with !connect jdbc:ignite:thin://172.19.0.2/ command in sqlline.
This does not work, and throws Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
IgniteJDBCThinDriver is installed/available.
Adding JVM argument
--add-opens java.base/java.nio=ALL-UNNAMED
solved the problem for me.
It is recommended to Java 8, as Apache Ignite 2.7.0 does not have full Java 12 support. Otherwise you can try tinkering with JVM options.
Thank you #alamar, that worked!
I uninstalled JDK12 that i had installed with RPM.
Check the package name:
rpm -qa | grep jdk.
Delete the package:
rpm -e jdk-12.0.1-12.0.1-ga.x86_64.
I'm working on a isolated system, so I downloaded and transferred JDK8.rpm from another machine.
Install JDK8:
rpm -ihv jdk-8u211-linux-x64.rpm.
Now when I run:
./sqlline.sh --verbose=true -u jdbc:ignite:thin://172.19.0.2,
I get:
issuing: !connect jdbc:ignite:thin://172.19.0.2/ '' '' org.apache.ignite.IgniteJdbcTh
Connecting to jdbc:ignite:thin://172.19.0.2/
Connected to: Apache Ignite (version 2.7.0#20181130-sha1:256ae401)
Driver: Apache Ignite Thin JDBC Driver (version 2.7.0#20181130-sha1:256ae401)
Autocommit status: true
Transaction isolation: TRANSACTION_REPEATABLE_READ
sqlline version 1.3.0.
I can now query my database.
I got this error in the following very strange situation:
A dependency of my maven java project had Apache-Ignite as a dependency. The moment I opened a connection to a SQLite database at an invalid path (e.g. ./result/r.sqlite where the folder ./result does not exist) this error occurred (using th driver org.xerial.sqlite-jdbc:v3.30.1.)So this call
Class.forName("org.sqlite.JDBC");
Connection conn = DriverManager.getConnection("jdbc:sqlite:result.sqlite")
would result in this stacktrace:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.apache.ignite.IgniteJdbcThinDriver
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at java.sql/java.sql.DriverManager.isDriverAllowed(DriverManager.java:555)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:674)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:251)
at MyClass.myMethod(MyClass.java:154)
So the solution would obviously be to make sure the folder exsits where the sqlite database should be created in.