It has been a while since I have posted. I have been working on some interesting stuff, but somehow didn’t manage to post about it. I will start to correct that.
I had a lot of work to do leading up to this past week. I had a couple of demos due for a big trade show at work. I hit a lot of bumps in the road due to infrastructure problems. I made a list, and I am working through them now that the deadlines are over. The next few posts will probably be about solutions to those.
The one covered here is pretty lame, but I’ll post it anyway.
Java Process Status command
I use the Java Process Status command line tool enough to want it to work perfectly. But, by default, it doesn’t. After launching Eclipse, I would execute JPS and get results like this:
plaird@plaird-laptop:~$ jps
18589 Jps
18339
If I launched multiple copies of Eclipse with different workspaces, I would predictably get:
plaird@plaird-laptop:~$ jps
19369
18339
19388 Jps
This isn’t a big problem, but its annoying. I put it on the list, and looked into it tonight. The reason is simple, and so is the solution.
JPS only works when using the standard Java launcher
The clue comes from the JPS documentation. It states:
The jps command uses the java launcher to find the class name and arguments passed to the main method. If the target JVM is started with a custom launcher, the class name (or JAR file name) and the arguments to the main method will not be available.
Well, that explains it because as many people know…
Eclipse uses a custom (native) launcher
After installing Eclipse, you are provided with a handy executable in the Eclipse directory. Invoking this thing launches Eclipse. Under the hood, it uses platform specific code to make it happen. The main benefit for doing this is to ensure that Eclipse is contained within a single OS process. The native code launches the JVM within its same process using a custom launcher. This appears to be a problem, but…
There is a way to use the standard launcher for Eclipse
However, you can revert to using the standard launcher. As per the launcher docs, there are several ways to do this. The way I chose is to make sure my eclipse.ini has these lines:
-vm
/usr/lib/jvm/java-6-sun-1.6.0.16/bin/java
Since the path for the vm arg is the standard Java launcher, it uses that instead of the custom launcher. Now look at my JPS results:
plaird@plaird-laptop:~$ jps
19369 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
18339 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
19388 Jps
Problem solved. Well…
Caveats
Sadly, this doesn’t solve the problem of identifying which workspace is in use by either. But as long as you remember the order in which you started them, in most cases the pids will be in order.
And the known downside of multiple processes is evident in a ps –ef command:
18325 1 /bin/sh /home/plaird/Apps/eclipse35/eclipse.sh
18326 18325 /home/plaird/Apps/eclipse35/eclipse
18339 18326 /usr/lib/jvm/java-6-sun-1.6.0.16/bin/java equinox.launcher.jar
20111 1 /bin/sh /home/plaird/Apps/eclipse35/eclipse.sh
20112 20111 /home/plaird/Apps/eclipse35/eclipse
20128 20112 /usr/lib/jvm/java-6-sun-1.6.0.16/bin/java equinox.launcher.jar
Which is worse – JPS not listing Eclipse or having more goo in a ps listing?
Random Footnote
I noticed this comment in the JPS docs:
The lvmid is typically, but not necessarily, the operating system's process identifier for the JVM process.
This means that the pid/lvmid reported by JPS cannot always be used in a kill command. Good to know.
No comments:
Post a Comment