I have already spent a long time to load and test my application, now I need to profile it. But unluckily, the VisualVM always says "not supported for this JVM" on my local applications?
The applications were started on the same JVM with VisualVM.
I found out that (at least under Windows) one can easily write small batch files to run VisualVM in combination with specific JVMs, which is important for me, since I have installed the 32bit JDK alongside with the 64bit JDK (I need both, so this is sensible for me).
I have created two batch files in the folder "S:\applications\visualvm\bin\":
run_32.bat:
#echo off
START "VisualVM 32" visualvm.exe --jdkhome "C:\Program Files (x86)\Java\jdk1.7.0_07"
run_64.bat:
#echo off
START "VisualVM 64" visualvm.exe --jdkhome "C:\Program Files\Java\jdk1.7.0_07"
Obviously, all paths may differ on your system, but the general idea should still work correctly (on all 64bit versions of Windows). The benefit is that I can use the 32bit batch file when I want to use VisualVM in combination with Java applications that run on the 32bit JVM, and so on for 64bit.
The "start" command has the only benefit that the batch file launches the application without waiting for it to finish, so the command prompt window closes immediately. This is not a feature of VisualVM, but of the Windows batch file interpreter.
In my case, even with the JVMs matching (both 64-Bit), the only way to get things working was sending the argument -Dcom.sun.management.jmxremote to the JVM to be monitored. That also works if you are having problems to connect via Java Mission Control (JMC).
According to JMX's documentation, this what the argument does:
Setting this property registered the Java VM platform's MBeans and published the Remote Method Invocation (RMI) connector via a private interface to allow JMX client applications to monitor a local Java platform, that is, a Java VM running on the same machine as the JMX client.
This was supposed to be enabled automatically, but for some reason it wasn't on my Linux.
VisualVM needs to be run with the same JVM - at least Java 6 with the same 32-bit/64-bit size - as the program to be profiled. (You also need to be the same user, but then this message does not apply).
I would be triple-check that it was the exact same JVM in your situation.
On Linux:
Make sure that your /etc/hosts correctly references the effective ip address of your "hostname"
It appears that a discrepancy here totally confuses the poor jvisualvm and its programmers.
I too got the same problem for local tomcat, I search for solutions for stackoverflow. after some serious debugging, I figured out that VisualGC don't have permissions to get GC informations from tool.jar file.
by links
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html#SECURITY
https://stackoverflow.com/a/42107355/3876619
I following steps to solve the issue
1) Create a permission file
vim /tmp/tools.policy
Add
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
save it
2) Now add /tmp/tools.policy to JVM startup parameters
-Djava.security.policy=/tmp/tools.policy
3) Run jvisualVm with sudo
An issue that I just found, thanks to the hint from #user3356656, is that if you start the program while your machine is on one IP, and then try to connect while it is on a different IP, it will fail.
I also met this issue. My case is that on linux, I started tomcat with tomcat_user but I run jvisualvm with root user. It works after I start tomcat with root user.
I was having the problem having of visualvm detect my local tomcat installation on Windows 7. I could connect manually, but then things like memory snapshots and visualgc plugin were not enabled. I confirmed that I was using same JVM version, temp file permissions, etc. Didn't work. Then I found that starting visualvm first, and then tomcat, solved the problem.
As you can see, you are running VisualVM on 32bit JVM
You don't need to unistall 32bit JVM. Just tell VisualVM to use tour 64bit JVM.
If you want to change it permanently, you can edit
in visualvm_13\etc\visualvm.conf and specify the path of jvm here
My problem was JVM optimizations - -XX:+PerfDisableSharedMem flag will break VisualGC. This is apparent if jps will not show your app in the listing.
I can reproduce next behaviour.
I have a java application with right-click menu item to open jvisualvm.
I'm running this java application as standalone setup from a bat file.
It means I modify %path% and other needed environment variables like JDK
accordingly to form my environment.
The BAT that starts application is marked running as non-admin. Environment points to a 64-bit JDK.
Then I start other java application as admin. VM lives from the to same 64-bit JDK-source.
Then I start jvisualvm from first app with the right click ie.as non-admin.
I can see the app in jvisualvm ‘Applications list’ but clickin ‘System properties’ gives error. Message is “Not supported for this JVM”.
JVM arguments are exposed.
Solution is like in some other previous comments:
Starting my right-click jvisualvm-starter as admin I can see also "system properties" .
Certainly if JDKs would be 32-bit and other 64-bit it would not work. been there.
I thought this notion needs to be added here.
In my case, the application was running with admin permissions. So, visualVM also need to be running as admin.
I have changed name to my Windows User and set it all lowercase, restarted my PC and it all works now.
For me, the reason is that I have run the "jstatd" with a different user with the JVM process. I have a special user in the linux to start the JVM thread(it is a tomcat), but I start the jstatd process with root. If you use root to run jps, you cannot see any information of the JVM threads belonging to other users. That is the trouble.
I killed the "jstatd" process started by root, su to the owner of the JVM process, and restart the "jstatd" process and everything wokrs fine now.
Related
This issue pertains specifically to Minecraft, but it is affecting all Java programs that run on my computer.
It would seem that something is forcibly setting a _JAVA_OPTIONS environment variable. When I run my server, I have specified to allocate 4 GB of RAM to it with
-Xms4G -Xmx4G
in the startup batch file. However, when the server runs, It prints "Picked up _JAVA_OPTIONS: -Xms2048M -Xmx2048M" to the console, only allocating 2 GB. I have checked my system settings and there is no _JAVA_OPTIONS environment variable in the list. I do not want to add one, since that will also try to allocate 4 GB to Minecraft itself, which is unnecessary and uses too much RAM.
What could be causing this variable to be set? (Windows 8.1 64-bit, Java 7)
You probably have a Razer device. Their god-forsaken software secretly adds _JAVA_OPTIONS, but only when launching games, so you won't even see it from CMD. Ideally uninstall the software, and maybe splash some holy water on your PC. Failing that, you can probably get by with shutting down Synapse and restarting minecraft.exe
Found (eventually) here: http://www.minecraftforum.net/forums/support/unmodified-minecraft-client/2183431-_java_options-picked-up-without-existing#reply
This error occurs actually when you run an android application after compiling a java program. Eclipse uses java's compiler to execute android application. So run your android application as an android application. Just right click on project and click on run as->android application instead of run configurations.
How can I specify that in order to run a certain java application that I created you need to have 32 bit JRE installed on your system? Further how can I specify that the java application is to use the 32 bit JRE and not the 64 bit JRE if they are both installed?
Background:
I have created an application that uses a 3rd party 32 bit only library. The application can not run in a 64 bit JRE.
I am going to be distributing this application to a lot of computers in my company, so I need to be able to in code or in the export process, specify the required JRE.
I am using eclipse, Kepler to develop and build the java application.
The idea of java is always compile once and run everywhere, regardless of OS, cpu architecture etc, so you might be heading the wrong direction here.
But nevertheless here are some system properties you might / not find helpful. I've listed the property key and value I have when I check it (I run Oracle JDK on Win7 64)
java.vm.name: Java HotSpot(TM) 64-Bit Server VM
sun.arch.data.model: 64
sun.cpu.isalist: amd64
To use any of those just do
String vmname = System.getProperty("java.vm.name");
You can't do it directly in Java, since you're in a running JVM at that point. My solution was to write a dos batch script to set the JAVA_HOME and add %JAVA_HOME%\bin at the front of the PATH. For example, I have sethome.bat which contains
#echo off
set "JAVA_HOME=c:\Program Files (x86)\Java\jre6"
set "PATH=%JAVA_HOME%\bin;%PATH%"
Then I use
call "%SERVICE_HOME%\sethome"
"%JAVA_HOME%\bin\java" -version
echo If this does not look correct press CTRL-C to cancel otherwise
pause
You cannot generally make sure what program runs your jar. I can pass the jar to acroread, or zip or whatever, and you can't do anything about it.
So, I'd just try to load the library, and do a proper error/exception handling. Who knows? Maybe your client has meanwhile replaced that library with a 64bit version, without you knowing about it? SO, this: loading, and if it won't aborting with a graceful eror message is the only sensible thing.
I have a tomcat instance with the JMXRemote parameter configured. The local VisualVM is able to get a sampler on CPU, however, not for Memory. The memory button is grayed out with a summary saying: "Memory sampling: Not available. Cannot connect to target application. Make sure the application is running on a supported JDK 6 or JDK 7"
JMXRemote parameter:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Tomcat JDK version:
JDK1.6.0.30
VisualVM version:
Version: 1.6.0_30 (Build 1320-110325); platform 110131-9c8b3bfb3a1e
System: Windows Server 2008 R2 (6.1) , amd64 64bit
Java: 1.6.0_30; Java HotSpot(TM) 64-Bit Server VM (20.5-b03, mixed mode)
Vendor: Sun Microsystems Inc., http://java.sun.com/
Environment: Cp1252; en_US (visualvm)
Userdir: C:\Users\Administrator\AppData\Roaming\.visualvm\7
Clusters: C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\platform
C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\visualvm
C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\profiler
Tomcat version:
Tomcat 6.0.32
I am running both the VisualVM and Tomcat at win server 2008. Anything i did wrong?
I had the same problem before.
You must have downloaded the version from jvisualvm homepage, right?
Don't do it!
If you use new jdk 1.7, VisualVM is already packaged in your jdk folder.
Use this version, you will not have any problem with memory sample.
This blog post leads me to believe that the temp directories of JVisualVM and Tomcat need to be the same for memory sampling to work. One of the comments on the post:
the temp directory must be set to the one used by JVisualVM, which can be discovered from the VisualVM system properties tab (java.io.tmpdir). Once I set the CATALINA_TMPDIR directory properly, this worked beautifully.
I've just run into this same issue and the answers above solved my problem but it took me a while to figure out how. Just in case anyone else is still having trouble and ends up this far down the thread, I was using the JDK that is part of the weblogic server configured through Eclipse and not the JDK that I installed seperately. I'm still a junior programmer and I wasn't putting 2 and 2 together until I started looking through my eclipse settings and verified my Installed JREs.
Ran the jvisualvm.exe from the weblogic jdk and all worked.
I would check the version of VisualVM is exactly the same as the JVM.
VisualVM is very version specific. I assume its still under fairly rapid development.
(Re posted as an answer as it may be the solution)
I've faced similar issues with JVisualVM, I've even asked a question about it here
A couple of insights/advices:
So, in order to sample memory you don't need jmx options.
I would double check whether you have 64 bit jvms installed along with 32 bit jdks on the same machine (even if they're not running and all the environment vars defined properly), I've read somewhere that sometimes it drives the JVisualVM crazy :) (yes I know it doesn't sound reasonable to us, java developers)
If it doesn't work, just uninstall all jdks that you have and install only 1 that you need. It can solve the issue.
I hope it will help you to resolve the issue, after all like Peter said these things are new and evolving
Here is my solution for similar problem: https://stackoverflow.com/a/16330238/715483
You can resolved this error by
$ ssh -Y user#remotemachine
$ wget http://java.net/projects/visualvm/downloads/download/release135/visualvm_135.zip
$ unzip visualvm_135.zip
$ cd visualvm_135/bin
$ ./visualvm
This instance of visualvm will be full featured, including memory and CPU sampling.
Read more about it here: http://shahriarinia.blogspot.com/2013/05/java-cpumemory-heap-usage-monitoring.html
http://mshahriarinia.com/
Make sure your VirtualVM/JDK is a 32-bit copy if your JRE is. If you are using Eclipse, check the selected JRE on Installed JRE's section.
And I have the same problem.
I always launched tomcat as a service and connected it with visualvm through jmx connection.
When had corrected catalina.bat:
set JAVA_OPTS=%JAVA_OPTS%
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
and launched it with startup.bat, visualvm automatically determine tomcat, and memory sampling was active.
I've got the same problem but with different envirnoment. My server was a Linux machine, the client a Windows 7 machine, but the problem is the same.
The solution was to launch the jvisualvm in the same machine and with the same user that is running the targeted application. If i run jvisualvm with other other user (ex: root) the memory button became gray.
Firstly, JMX should be enabled. Add the linked command line environment variables necessary to activate JMX if you haven't.
The environment variable CATALINA_TMPDIR should be set to match the JVisualVM as seen in the "System properties" tab of the Local > VisualVM. You can open this by double clicking on the "VisualVM" labeled entry in the Applications pane on the left.
Environment variables can be set by searching for environment, "edit environment variables for your account". New... > Enter a name and value.
If you would like the temporary directory of VisualVM to be somewhere else, you'll have to launch VisualVM from the command line and add an argument.
C:\Program Files\Java\jdk1.8.0_65\bin>jvisualvm.exe -J-Djava.io.tmpdir=C:\Users\You\Temp
We have a Java process which we run as a Windows service (using srvany). It runs with Java 1.6 (1.6.0.23 at the moment).
In the past (Windows XP), I could connect JConsole to the processes, on Windows 7 I cannot do this anymore.
If I run jconsole <pid> I get “Invalid process id:4488”. The services are running as SYSTEM user.
If I make the service run as my desktop user (using “Log On as This Account”) the services process ID appear in JConsole, but they are grayed out and I cannot connect.
Is it impossible to dynamically connect to Java processes when they are running as a Windows 7 service?
Perhaps it is a 64bit/32bit problem, I have several applications compiled with 32bit JDK, which could not be opened with JConsole from 64bit JDK on Windows 7 64bit, after I downloaded the 32bit JDK it worked.
Others have been able to run jstack on 2008r2 which may provide some insight on how to get jconsole to connect on Windows 7. As you noted in your comment, the permissions are important. If the service and jconsole can't access the temp directory to write to the appropriate hsperf subdirectory, it won't work. What is also important is the location of the temp directory, the user the service is running, and the user that is running jconsole.
Running SysInternals psexec -s -i <jdk_home>\bin\jconsole <PID> can be used to run jconsole as Local System, the same user that I believe you are using to run your service.
My experience running jconsole from JDK 1.5 in Server 2008 as a system user was unsuccessful. With permissions that I thought should have been sufficient, I got a Could Not Open PerfMemory error. Java 1.6 may be a different story.
In light of all the challenges with running jconsole locally, you would probably have better luck setting it up to accept remote connections. You could set it up for local-only access with your firewall blocking that port from external access.
Add the following to JAVA_OPTION
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Then,
Use JConsole to connecet remote session:
localhost:8086
I am currently facing the same problem but on Windows 2003 R2 (SP2). There is on open bug in Oracle Bug database (bug id 6399729)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6399729
Also there is a work-around posted towards the end. It talks about installing java in "install" mode :-), but didn't work for me on Windows 2003 though. But your mileage may vary!!
Change Environment Variable TEMP and Tmp to a different folder that you created.
Like c:\theTemp
It might be a problem with the folder %TMP%/hsperfdata_{USER_NAME}.
In my case, it worked after I :
close all applications running over the JVM
delete the folder %TMP%/hsperfdata_{USER_NAME} (exemple: C:/Temp/hsperfdata_MyUser)
reopen JConsole (it recreates the folder)
Hope it helps. You can also take a look at this thread in Oracle community.
Up until recently, I was able to launch/open JNLP files in Firefox using Java web start.
Don't know what happened all of a sudden JNLP files stopped launching, a splash screen appears saying Java Starting... and then nothing happens. Even the Java Console in the browser and javacpl.cpl applet doesn't open.
Tried all possibilities: removed all older version and installed the latest JRE (java version "1.6.0_17"), still it doesn't work.
Done some googling for this problem, people suggested to start javaws.exe with -viewer option but same behavior (a splash screen appears saying "Java Starting..." and then disappears)
The problem is that I don't know any place (logs etc.) to look for to see what is causing the problem.
I am using WinXP SP3, and some of the screenshots below shows further info about my system.
I can provide any other detail if required but please help me solve this problem.
Have a look at what happens if you run javaws.exe directly from the command line.
I know this is an older question but this past week I started to get a similar problem, so I leave here some notes regarding the solution that fits me.
This happened only in some Windows machines using even the last JRE to date (1.8.0_45).
The Java Web Start started to load but nothing happened and none of the previous solution attempts worked.
After some digging i've found this thread, which gives the same setup and a great explanation.
https://community.oracle.com/thread/3676876
So, in conclusion, it was a memory problem in x86 JRE and since our JNLP's max heap was defined as 1024MB, we changed to 780MB as suggested and it was fixed.
However, if you need more than 780MB, can always try launching in a x64 JRE version.
i had the same problem here. go to your Java Control Panel and Settings... Uncheck 'Keep temporary files on my computer'. Apply changes and try again your .jnlp
Note: Tested on different machines; Windows Server 2012, Windows Server 2008 and Windows 7 64bit.
Java Version: 1.7++ since my jnlp app is built on 1.7
Please let me know your feedback too. :D
Java web start should be enabled.
Check if javaws (Java web start is enabled for your system), Use below command in console to open java control panel.
javaws -viewer
If javacpl does not open and gives you Could not find the main class:, it could be that Java is confused because of changes in deployment.properties (can be found in C:\Users\<username>\AppData\LocalLow\Sun\Java\Deployment on Win7). Delete that file and everything's fine.
This bug seems to be 6 years old, cf. An app should be able to ignore properties that have become obsolete over time, shouldn't it?
Although this question is bit old, the issue was caused by corrupted ClearType registry setting and resolved by fixing it, as described in this ClearType, install4j and case of Java bug post.
ClearType, install4j and case of Java bug Java
Do you know what
ClearType (font-smoothing technology in Windows) has in common with
Java (programming language and one of the recommended frameworks)?
Nothing except that they were working together hard at making me
miserable for few months. I had some Java software that I couldn’t
install. I mean really couldn’t – not even figure out reason or
reproduce it on another PC.
Recently I was approved for Woopra beta (site analytics service) and
it uses desktop client written in Java… I couldn’t install. That got
me really mad. :)
Story All of the software in question was similar :
setup based on install4j; setup crashing with bunch of errors. I was
blaming install4j during early (hundred or so) attempts to solve
issue. Later I slowly understood that if it was that bugged for that
long time – solution would have been created and googled.
Tracing After shifting focus from install4j I decided to push Java
framework. I was trying stable versions earlier so decided to go for
non-stable 1.6 Update 10 Release Candidate.
This actually fixed error messages but not crashes. I had also noticed
that there was new error log created in directory with setup files.
Previously I had only seen logs in Windows temporary directory.
New error log was saying following :
Could not display the GUI. This application needs access to an X
Server. If you have access there is probably an X library missing.
******************************************************************* You can also run this application in console mode without access to an
X server by passing the argument -c Very weird to look for X-Server on
non-Linux PC, isn’t it? So I decided to try that “-c” argument. And
was actually able to install in console mode.
Happy ending? Nope. Now installed app was crashing. But it really got
me thinking. If console works but graphical interface doesn’t – there
must be problem with latter.
One more error log (in application folder) was now saying (among other
things) :
Caused by: java.lang.IllegalArgumentException: -60397977 incompatible
with Text-specific LCD contrast key Which successfully googled me
description of bug with Java unable to read non-standard ClearType
registry setting.
Solution I immediately launched ClearType Tuner from Control Panel and
found setting showing gibberish number. After correcting it to proper
one all problems with Java were instantly gone.
cleartypetuner_screenshot Lessons learned Don’t be fast to blame
software problems on single application. Even minor and totally
unrelated settings can launch deadly chain reactions. Links Jave
Runtime Environment http://www.java.com/en/download/index.jsp
ClearType Tuner
http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
Woopra http://www.woopra.com/
install4j
http://www.ej-technologies.com/products/install4j/overview.html
I was also facing the same problem. To fix this to the following steps.
open Javaws from cmd runnig javaws -viewer command. A new window will open
Select the jnlp file which you want and click the run button.
Close the javaws viewer window.
Same solution worked as suggested by hpereira
The issue was due to JRE version was 32 bit and not 64 Bit
Check with java -version to see if your Java is 64 bit
C:\>java -version
java version "1.8.0_192"
Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
Java HotSpot(TM) **64-Bit Server** VM (build 25.192-b12, mixed mode)
Is this an application to which you have the code? Java 6u14 included a change to the way it handles jar security that for us caused very similar issues. If your jars are signed and work with Java 6u13 or below, you might consider either refactoring your code to work around this update or requiring Java 6u13 or below. Unfortunately I don't recall exactly what we did to resolve the issue - it was panic mode at the time.
Again, if you have the code you have tools to work with. You can put in System.out.println statements in your startup routines - anything console output is displayed in the command window when you run the JNLP from the command line. Otherwise you might consider using a nice logger like log4j to get a better idea of the point of failure.
You may also consider removing the application entirely and downloading it anew. Java Web Start has a Control Panel applet that allows you to see the URL your app is downloading from (could be the wrong one), uninstall the app, set security options, etc.
I had the exact same problem. Turned out that the max-heap-size was set to 1024 and missing the unit. The configuration needed to be max-heap-size=1024m.
So apparently invalid memory configuration in the jnlp file will cause this exact behavior.
In my case, the problem was caused by starting my app from a shortcut on the public desktop (windows 7). As a result, as far as I can tell, the temporary files location was set to c:\users\public\etc. This resulted in the unable to write to cache detail. When I reset to defaults in the temporary files control applet, all worked fine.
In my case, Netbeans automatically creates a .jnlp file that doesn't work and my problem was due to an accidental overwriting of the launch.jnlp file on the server (by the inadequate and incorrect version from Netbeans). This caused a mismatch between the local .jnlp file and the remote .jnlp file, resulting in Java Web Start just quitting after "Verifying application."
So no one else has to waste an hour finding a bug that should be communicated adequately (but isn't) by Java WS.
This can also be due to environment variable CATALINA_HOME in your system. In our organization there were several cases where JNLP applications just refused to start without logging anything and emptying CATALINA_HOME solved the issue.
I had the environment variable set in the command prompt and it didn't appear in GUI. I'm not sure if setx command or register removal commands did the trick. Restart seems to be necessary after removing the variable.
I believe this is a security problem. If I download the jnpl file and execute it after a clean java 8 installation via javaws myfile.jnpl everything is working fine (I get multiple windows where I have to confirm some security problems).
I wanted to share the root cause for my issue. I was using High DPI in Windows and this caused JNLP to not launch. I had to turn off High DPI for this to work. Hope this helps.
Try Java Web Launcher, rather than Java Web Start Launcher. It worked for me.
Right-click on the JNLP file that is not opening and select Open With.
In the ‘How you want to open this File’ window, scroll down and click on Look for another app on this PC option.
When the File Explorer window opens, navigate to the following location:
C:\Program Files (x86)\Java\jre1.8.0_261\bin
or the folder for 64bit version
Select javaws.exe and click the Open button. This will open the JNLP file as intended.
Make sure to check the Always use this app to open .jnlp files.
That's all.