Bugzilla – Full Text Bug Listing
| Summary: | Profiling with an incorrect path creates a Java failure to launch dialog | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Joel Cayne <jcayne> |
| Component: | TPTP | Assignee: | Mike Reid <mikereid> |
| Status: | CLOSED WONTFIX | QA Contact: | Kathy Chan <kathy> |
| Severity: | normal | ||
| Priority: | P2 | CC: | jgwest, mikereid |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Server 2003 | ||
| Whiteboard: | post472 | ||
|
Description
Joel Cayne
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. |