Community
Participate
Working Groups
Using TPTP-4.7.0-201004281900, create a new Profile Launch configuration. In the Main tab enter a path that is incorrect for the Class file. Using Java 6 (64-bit on Windows x86_64) it prints to the console: Exception in thread "main" java.lang.NoClassDefFoundError: StartStop Caused by: java.lang.ClassNotFoundException: StartStop at java.net.URLClassLoader.findClass(URLClassLoader.java:419) at java.lang.ClassLoader.loadClass(ClassLoader.java:643) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:320) at java.lang.ClassLoader.loadClass(ClassLoader.java:609) In addition, a dialog appears on the machine running the Agent Controller with "Could not find the main class. Program will exit." for every launch. For Java 5 it only prints to the console "The java class is not found: StartStop".
This behaviour comes as a side-effect of the fix implemented for bug 308169. In order to the read output stream of the launched process without any character conversion occurring, the javaw.exe executable needs to be used instead of java.exe. I had another look at CreateProcess and through the docs and experimentation I was unable to find a way to launch java.exe while retaining the ability to read the raw output stream. Similary I was unable to find a way to somehow block the ability of javaw.exe to open message dialog windows as it does in JVM 1.6. At present it is unclear if we can correct this behaviour without compromising the fix for bug 308169.
With more investigation there are some ways we can deal with this, but none are low-cost and so we will need to push this out to a future release. Some of the options include: - Write a custom JVM launcher using JNI invocation interface - Examine console output for the 'telltale' missing main message: "Exception in thread "main" java.lang.NoClassDefFoundError: StartStopNew - Finally, on the AC side we can try and detect a well-defined state of the JVM where we can be sure this happened and kill the process (which closes the message dialog). e.g. interrogate the JVM for running threads and if all are stopped we kill the process. There are pros and cons in all of these that need to be further investigated when this is looked at again.
From the above options the only robust solution is the first; however it adds an unnecessary burden to future maintenance and so given the low impact of this issue it does not seem an appropriate use of resources. Looking at this behaviour again, there are two mitigating factors: 1) On the workbench side, the agent appears to be running still; the process can be terminated from the workbench as normal and this dismisses the window on the remote machine. 2) If the user does not notice that the agent is still running, from observation it appears that by closing the workbench the remote process is terminated as well, dismissing the window. With these in mind it seems unlikely this will be encountered frequently if at all. However it is worth documenting this in the event that it is discovered. Pushing out from 4.7.2 to address documentation in future.
No plan to fix.
Closing.
