Community
Participate
Working Groups
Steps: 1> Configure the Agent Controller with JVM 1.4 and 1.5 on two separate hosts 2> Open the profiling launch configuration 3> Add the two hosts under the host tab 4> Select the host with JVM 1.4 and switch to the monitor tab. Make sure that only the JVMPI data collector is displayed 5> Switch back to the host tab and select the host with JVM 1.5 6> Switch to the monitor tab and make sure that only the JVMTI data collector is displayed 7> Repeat the different host selections and make sure that the monitor tab is updated according to the host selection On step 4, I saw both JVMPI and JVMTI options displayed. Selecting the JVMTI option and proceeding with the launch results in an error from the 1.4 JVM saying the -agentlib option is not recognized. Reproduced with: - TPTP-4.7.1-201008231141. - Remote machine was Linux, running AC 4.6.2 configured with IBM JDK 1.4.2sr13 - Security disabled on both local and remote systems
Hi Mike, Could you please check if this is a regression problem or not?
I am no longer able to reproduce this with TPTP-4.7.1-201009071107 (RC3).
This began happening again today. With further testing, the problem seems to be on the AC side. It is not yet clear if there are specific conditions to cause or if it is timing-based, but what seems to happen is the AC fails to respond in an appropriate way to the workbench. This causes the job which populates the available collectors to either timeout and then display both 1.5 and pre-1.5 collectors; or to hang indefinitely. It seems that by enabling the Java file server in serviceconfig.xml works around the problem: <TransportLayer loadlib="tptpCCTL" type="TPTP_CCTL"> <Configuration> ... <JavaUnsecuredFileServer>true</JavaUnsecuredFileServer> ... </Configuration> <CommandExtractor>tptpCmdExtr</CommandExtractor> </TransportLayer>
With additional testing it seems that part of the problem was firewall interfering with some of the needed communications between AC / workbench. Second, on Linux, the proper hostname seems to be detected incorrectly depending on the machine's network configuration, which again throws off some of the communication between AC and workbench. It is not entirely clear at the moment what the failures on Windows were caused by. However, it does seem to be a rare occurrence when running the workbench on Windows.
At this point I'm closing this as I believe all of the problems were due to issue in the two environments that we saw this occur. With proper hostname setup and firewall that allows the needed connections I have not seen this problem recur in the 4.7.2 cycle. Resolving invalid.
Closing.
