Develop Reference

windows discriminate java processids

I'm developing a web application with Eclipse and Tomcat on windows. When testing my efforts I sometimes crash Tomcat, and the only option left is to kill the jvm hosting Tomcat, but that can only be done with windows' task manager.
The process to kill is a java process but eclipse is also on a java process and basically the only thing I can do determine which java process to kill is toss a coin and hope for the best. It seems that I choose the wrong (eclipse) java process more often than the tomcat java process. Of course I can and should write down the id of the only java before starting Tomcat but that is sometimes forgotten
Is there a way to determine which java process is for eclipse and which for Tomcat? when eclipse is up an running for a long time I can discriminate on the cpu time, but for short running instances this is no candidate for heurstics.

I use Process Explorer which is free and I can easily see in its GUI (in process tree view) that eclipse is a super node of Tomcat's JVM.

Use the Process Explorer from Sysinternals. It shows the hirarchy of processes, and since the Tomcat got started by Eclipse, you can see it as a “subprocess”.

You could start jvisualvm from the bin of your JDK directory. There each MainClass is listed with the corresponding pid.

Java daemon deployment

I have a console Java application, which runs all the time on a remote server (nohup java -jar myapp.jar &).
Frequently (every other day) I need to replace the JAR file by a newer one (whenever I fix a defect).
At the moment I do this by connecting to the server using ssh (WinSCP).
How can I create a mechanism, using which I could upgrade the application via the http protocol? Can I use JMX for that?
That mechanism should do following things:
a) Stop the currently running application.
b) Upload the new JAR file to the server.
c) Launch the new JAR file.

Basically you need to break down the program into two parts:
the monitor component which fetches the new jar, stops the program, replaces the jar, restarts the program
the actual program, the console java application
Theoretically you can do all of this in a single java process but the additional complexity is not worth the trouble in my opinion.

You might check out install4j or this similar StackOverflow question.

In LiveRebel, there's native support for standalone applications (i.e. daemons). So the main application is running with the watchdog agent which communicates to the command center. From command center it is possible then to manage the updates.

Local java processes are grayed when trying to connect via JMX

I'm running a number of java processes on a windows XP professional machine. When i attempt to connect to these processes via a local JConsole the processes are grayed out.
However i can run the same processes on another machine and connect via a local JConsole on that machine.
Both machines are running java 1.6 version for the processes and jconsole.
Any ideas why these processes are grayed out?

I'm fighting with this issue right now and I found out a work around:
You can change the local user's temp dir to something that they can definitely access (e.g. D:\temp). Make sure to do this for the process you're trying to monitor and the jconsole process.
Another thing that can apparently cause issues are usernames with uppercase letters in them. The directory will always be created with all lowercase letters, but simply renaming it to exactly how it's being shown in the Task Manager made all the issues go away: http://planeofthought.com/wp/?p=75

if the processes are running as a different user (e.g. if you start them as services), then you won't be able to connect to them. also, if they are running under an older jvm, you most likely won't be able to talk to them either.
in some cases, the local jmx communication mechanism uses the local filesystem and may have issues if permissions are not defined correctly. are you possibly running any of these processes on networked filesystems (nfs, samba)?

Say your windows user name you use to start your java application seen in task manager is YOUR_USER_NAME.
Please check a folder whose name looks like hsperfdata_XXXXX (XXXXX should be your user name) in your temp folder and make sure YOUR_USER_NAME and XXXXX are exactly the same (be careful about the upper and lower case).

From http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html:
Applications that are not attachable, with the management agent disabled. These include applications started on a J2SE 1.4.2 platform or started on a J2SE 5.0 platform without the -Dcom.sun.management.jmxremote or com.sun.management.jmxremote.port options. These applications appear grayed-out in the table and JConsole cannot connect to them. In the example connection dialog shown in Figure 3-1, the Anagrams application was started with a J2SE 5.0 platform VM without any of the management properties to enable the JMX agent, and consequently shows up in gray and cannot be selected.
(source: oracle.com)
Despite what's being written in the documentation, most likely your process is running under a different user. You can run jconsole as an administrator and try then.

Here is what worked for me. I changed my %TEMP% and %TMP% environment variables to point to a folder I created in my %HOME% location (like C:\Users\[YOUR_NAME]\Temp). Once I did this, all problems vanished.

I had the problem as described earlier, but was advised a simpler solution: just close all programs using Java ("IntelliJ IDEA", "SoapUI", etc. - to unlock the temporary folder) and then delete %TMP%\hsperfdata_<user.name> folder. Then, after opening any Java program, this folder will be recreated but this time with correct name (most likely %TMP%\hsperfdata_<User.Name>). And after that, local Java processes can be monitored through "JConsole" or "VisualVM" (now runs without starting error with a link to VisualVM: Troubleshooting Guide) again.

instead of this steps you can just goto the CMD and then type in jconsole.exe (PID)
Remember to go to the path where jconsole is present and then run the executable file.

Change the name of the hsperfdata folder which for me was found at C:\Users\pmimgg0\AppData\Local\Temp\hsperfdata_pmimgg0 to match the User name found on task manager. Once I changed hsperfdata_pmimgg0 to hsperfdata_PMIMGG0 my local process was no longer greyed out on jconsole.

Change your TEMP paths in Environment Variables to something like D:\temp as it could be a permission issue. Fixed this issue for me

The best way is to run local process like a remote process.
Add these conditions in runtime arguments -
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=6001
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.rmi.port=6001
Then select Remote Process and point to localhost:6001 as shown
Click Connect and Jconsole is connected successfully.
For me this fixed as I had some admin constraints.

Java based usb application

I working on a Java based application which can be carried around by the user in a USB flash Drive. At the startup I want to check for existing JVMs on the machine the USB is plugged-in.
How can I achieve it ???

Investigate JSmooth -- http://jsmooth.sourceforge.net/ --
or Java Web Start in newest Java 6.
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/cdinstall.03.06.html

If you wrap the program in an .exe wrapper - as Launch4j - it can check for JVM installation,
before each execution.

Isn't this a chicken-and-egg situation?
Your Java program needs to be launched in a JVM before it can run its logic to look for JVMs. And at the point it can look, a JVM has already been found so I don't think you could do anything particularly useful with it. (Unless your "main" app is actually a tiny bootstrapper, which chooses the JVM it wants and uses Runtime.exec to launch the real application.)
In any case, I would suggest that it's not the responsibility of the application to choose which JVM it wants to run in; the user will set up his environment to run with the JVM he wants, and I'd consider it rude to ignore this and force your own choice on him (which is likely to be made with less knowledge about the relative merits of those JVMs).

The shutdown hook isn't executed when the application is launched using javaw.exe

If I'm using javaw.exe to launch a Java application, the shutdown hook isn't executed when users log off from their Windows account. The application is actually launched using a launch4j generated .exe file but I know it uses javaw.exe to start it.
This seems to be a known bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302814
Has anyone else had this problem? If so, how did you fix it?
Thanks!

The application is actually launched using a launch4j generated .exe file but I know it uses javaw.exe to start it.
I haven't used launch4j in a while, but I'd be fairly suprised if it directly did this. Most of these apps start the jvm themselves, rather than shelling out to javaw.
The only difference between java.exe and javaw.exe is that java.exe automatically attaches a console. The bug that you reference (and the others referenced by it) were closed as Sun doesn't appear to be interested in making the handling of Windows logoff events better. From what I can tell, it only works with java.exe, because the console itself handles the WM_MESSAGES in such a way that it slows down the shutdown process.
It appears that the only easy workaround at the moment is to change the "headerType" in your launch4j config to "console". Obviously, this brings with it an ugly console.
I think the other alternative would be to use some sort of native wrapper of your on that handles windows messages in a cleaner way.