JMC Java Flight Recorder not enabled - eclipse

I am using spring tool suite with the java mission control plugin to start an app which I would like to monitor using the JFR. I added -XX:+UnlockCommercialFeatures -XX:+FlightRecorder to the SpringToolSuite4.ini and additionally set JAVA_OPTS with those two flags (both of which is not necessary if I understand it correctly) and -XX:+FlightRecorder in Run configurations > Arguments > VM arguments of the application to be monitored. When adding both flags as well to the run configuration the application cannot be started with the openJdk.
After starting the application in the JVM Browser when selecting the Flight Recorder I get the following exception.
java.lang.RuntimeException: Flight Recorder features are not enabled. To enable this you need to use a Java 7u4 or later JVM started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
at com.oracle.jmc.flightrecorder.controlpanel.ui.FlightRecorderProvider.refresh(FlightRecorderProvider.java:105)
at com.oracle.jmc.browser.views.JVMBrowserView$1.run(JVMBrowserView.java:98)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: com.oracle.jmc.rjmx.services.jfr.FlightRecorderException: Flight Recorder features are not enabled. To enable this you need to use a Java 7u4 or later JVM started with -XX:+UnlockCommercialFeatures -XX:+FlightRecorder.
at com.oracle.jmc.flightrecorder.controlpanel.ui.FlightRecorderProvider.getService(FlightRecorderProvider.java:161)
at com.oracle.jmc.flightrecorder.controlpanel.ui.FlightRecorderProvider.refreshRecordings(FlightRecorderProvider.java:117)
at com.oracle.jmc.flightrecorder.controlpanel.ui.FlightRecorderProvider.refresh(FlightRecorderProvider.java:94)
... 7 more
I tried it with the following java versions.
$ java -version
openjdk version "11.0.2" 2018-10-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.2+7)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.2+7, mixed mode)
or with the JDK from oracle
$ java -version
java version "11.0.2" 2019-01-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.2+9-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+9-LTS, mixed mode)
For none of the above mentioned JDK's there is a jmc.exe which was there with java 8. Is that part of the plugin?
How can I get this running?

IIRC, Java 11 requires JMC 7 to be able to start and view recordings.
JMC 7 EA builds are expected to appear here soon - https://jdk.java.net/jmc/
In the meantime you can build JMC yourself, see http://hg.openjdk.java.net/jmc/jmc7/ (or github, not exactly sure which version it is synced to - https://github.com/JDKMissionControl/jmc) and the README on how to build.
You can start recordings using JVM command line flags, and using jcmd, and parse the recordings using https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jfr/jdk/jfr/consumer/package-summary.html

Related

Glassfish5 not starting

i have tomcat working fine, the error is not even about the port, which i know how to change, is this some sort of java version compatibility problem?
i'm a student so i don't know much
here's the output
$ asadmin start-domain domain1
Exception in thread "main" java.lang.NullPointerException
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.initializeServiceLocator(AbstractModulesRegistryImpl.java:152)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.newServiceLocator(AbstractModulesRegistryImpl.java:144)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createServiceLocator(AbstractModulesRegistryImpl.java:218)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createServiceLocator(AbstractModulesRegistryImpl.java:224)
at com.sun.enterprise.module.single.StaticModulesRegistry.createServiceLocator(StaticModulesRegistry.java:88)
at com.sun.enterprise.admin.cli.CLIContainer.getServiceLocator(CLIContainer.java:217)
at com.sun.enterprise.admin.cli.CLIContainer.getLocalCommand(CLIContainer.java:255)
at com.sun.enterprise.admin.cli.CLICommand.getCommand(CLICommand.java:231)
at com.sun.enterprise.admin.cli.AdminMain.executeCommand(AdminMain.java:371)
at com.sun.enterprise.admin.cli.AdminMain.doMain(AdminMain.java:306)
at org.glassfish.admin.cli.AsadminMain.main(AsadminMain.java:57)
the command $ asadmin list-applications says the server is not up
i'm on Mx Linux fully updated
$ java -version
openjdk version "11.0.16" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Debian-1deb11u1, mixed mode, sharing)
i haven't done anything yet, i can't find any problem similar to this on google
It was the JDK version
Inside netbeans when i clicked on Start to start the server, it says something about JDK 11, netbeans has a feature that let's you download many open JDK versions, i downloaded a random openJDK8 version and it worked
I don't know how to edit the JDK version manually or from any other IDE though, but my (video) class is using netbeans so for now i'm ok (they didn't teach on video because the video is 2 years old so it's outdated)

sdkman! How to manage pre-existing JDK?

I wanted to try Java 19 and have easy switching back to the Java 17 that I have already installed.
So, I installed sdkman but it knows nothing of the previous Java.
Found the "install local" command, used it to link the java 17 location to a unique name and sdkman seems happy, as it reports "Done installing!".
After that the "sdk current java" returns "Not using any version of java".
So then I tried "sdk use java [my unique name]. That was also accepted.
But still the "sdk current java" response is unchanged.
Have I misunderstood how this should work? I want to be sure sdkman knows what is there already before I add another Java.
Thanks for your advice!
Terminal commands follow (Kubuntu 22.04)
john#NUC8i3BEH:~$ java -version
openjdk version "17.0.4.1" 2022-08-12 LTS
OpenJDK Runtime Environment (build 17.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM (build 17.0.4.1+1-LTS, mixed mode, sharing)
john#NUC8i3BEH:~$ sdk install java 17.0.4.1-Bellsoft /usr/lib/jvm/bellsoft-java17-full-amd64
Invalid version! 17.0.4.1-Bellsoft with length 17 exceeds max of 15!
john#NUC8i3BEH:~$ sdk install java 17.0.4.1-Bell /usr/lib/jvm/bellsoft-java17-full-amd64
Linking java 17.0.4.1-Bell to /usr/lib/jvm/bellsoft-java17-full-amd64
Done installing!
john#NUC8i3BEH:~$ sdk list
john#NUC8i3BEH:~$ sdk current
No candidates are in use
john#NUC8i3BEH:~$ sdk current java
Not using any version of java
john#NUC8i3BEH:~$ sdk list java
john#NUC8i3BEH:~$ sdk use java 17.0.4.1-Bell
==== BROADCAST =================================================================
* 2022-09-21: neo4jmigrations 1.12.0 available on SDKMAN! https://github.com/michael-simons/neo4j-migrations/releases/tag/1.12.0
* 2022-09-21: micronaut 3.7.0 available on SDKMAN!
* 2022-09-20: quarkus 2.12.3.Final available on SDKMAN! https://github.com/quarkusio/quarkus/releases/tag/2.12.3.Final
================================================================================
Setting java version 17.0.4.1-Bell as default.
Using java version 17.0.4.1-Bell in this shell.
john#NUC8i3BEH:~$ java -version
openjdk version "17.0.4.1" 2022-08-12 LTS
OpenJDK Runtime Environment (build 17.0.4.1+1-LTS)
OpenJDK 64-Bit Server VM (build 17.0.4.1+1-LTS, mixed mode, sharing)
john#NUC8i3BEH:~$ sdk current java
Not using any version of java
john#NUC8i3BEH:~$
OK, I should have tried harder.
I installed Java 19 with sdkman then the command "sdk default java [my old version]" switches back as required.

java web start fails to locate java runtime

Hi I am trying to run javaws but it prompts:
To open this Web Start application you need to download the Java Runtime Environment.
I am sure JRE is installed, maybe javaws does not find it, how do I fix that?
Johns-MacBook-Pro:~ johnmactavish$ java --version
java 13.0.2 2020-01-14
Java(TM) SE Runtime Environment (build 13.0.2+8)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.2+8, mixed mode, sharing)
Johns-MacBook-Pro:~ johnmactavish$ javaws
No Java runtime present, requesting install.
Unable to locate a Java Runtime to invoke.
Johns-MacBook-Pro:~ johnmactavish$
Java Web Start (javaws) was deprecated in Java 9 and removed in Java 11.
As you are using java 13, you can either downgrade from 13 to 8, or look for alternatives.
Perhaps an alternative such as https://openwebstart.com/ can help you out with that.
P.S: In case you're using tools to manage version such as sdkman or such, there might be the case where it's also not available in SDKs # version 8 provided by sdkman.

Starting kafka on Linux or Win

I have tried for the last 10 hours to start the kafka server but I couldn't.
I managed to install zookeeper and run it on win10 but I had the
classpath is empty. please build the project first e.g. by running 'gradlew
jarall'
error.
So I installed ubuntu and the jre 9, zookeeper workd fine here ,too. But kafka does not. The latest error I get is:
[0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:/home/emi/kafka/bin/../logs/kafkaServer-gc.log instead.
Unrecognized VM option 'PrintGCDateStamps'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I even switched to java 8 and tried different versions of kafka, but I can't get it going. In both cases I don't think it's a problem of environement variables for java since zookeeper works just fine: java -version returns
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
Problem solved on Windows, probabily using the source file instead the scala compiled was the problem

"Error: Writing to server" - Occuring only on ubuntu

I am using a jar file implementing custom functionality which uses jersey as REST client (version 2.22.1). While everything seems to work fine for a few calls, for a specific HTTP call I get a "Error: Writing to server", but only when running in ubuntu.
The error occurs when running a unit test on my two ubuntu development PCs. My development PCs are both Ubuntu 16.04 with Oracle JDK:
~$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
$ java -version
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
Running the same test from a windows machine, gives me no error. On my windows machine:
java -version
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
The full error's stacktrace is:
javax.ws.rs.ProcessingException: java.io.IOException: Error writing to
server at
org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:287)
at
org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:255)
at
org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:684)
at
org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:681)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at
org.glassfish.jersey.internal.Errors.process(Errors.java:297) at
org.glassfish.jersey.internal.Errors.process(Errors.java:228) at
org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:444)
at
org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:681)
at
org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:437)
at
org.glassfish.jersey.client.JerseyInvocation$Builder.put(JerseyInvocation.java:326)
....
Caused by: java.io.IOException: Error writing to server at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:666)
at
sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:678)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at
org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:394)
at
org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:285)
... 40 more
I can only suppose two causes for the error:
the difference of the jvm version
different networking settings among the two operating systems
This error comes up in specific requests with rathed large http loads. Many colleagues in various posts have suggested that this occurs during large http requests, however I have not found any post suggesting a solution or relating it to Ubuntu specifically.
Any hints?
Which would be the networking parameters affecting such functionality? How could I change/adapt them?
Would specific jvm configuration be needed?
The solution is on the TCP level and not on the JVM version or configuration. I have changed the my ubuntu networking settings and the error is gone. I suppose, it occured only to large HTTP requests, because the TCP windows were too small or something.
I followed the instructions in http://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl article to set the following settings:
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.ipv4.tcp_rmem = 4096 137380 16777216
net.ipv4.tcp_wmem = 4096 137380 16777216
Please note that the error occured on an HTTP request with a load of about 90kbytes. I needed to play around with the value of the window assigned to each TCP connection (137380) in order to succeed.
Please also note that this could have other side effects in your networking that I cannot really foresee or explain. Testing with larger window values caused delays in other requests that I cannot explain. Therefore, increasing the TCP windows size is not a suits-all solution.