Community
Participate
Working Groups
Agent Controller does not appear to be available (IWAT0016E) when FIRST connecting to an Agent Controller with security enabled. Using the TPTP-4.3.0-200610160100 build, connecting to an Agent Controller (e.g. test execution, test connection, etc.) with security enabled for the first time (e.g. no security certificates for the target host), the Agent Controller does not appear to be available: IWAT0016E The Agent Controller is not available on host cindyjin.Make sure that: * the Agent Controller is installed. * the Agent Controller is configured to communicate with your machine. * you have the correct host name and port number for the Agent Controller. Connecting for the second and subsequent times works. Note: The error message is not well formatted (e.g. space(s) after the period).
Increasing severity since blocking Test project test cases.
Is this really happening on All platforms? Please attach servicelog file (set logging level=DEBUG, type=Simple), as this may show the same problem reported in bug 159677.
(In reply to comment #2) We have seen this behavior on: -Windows XP -> Windows XP -Windows XP -> Linux (x86)
Created attachment 52274 [details] Service log (Linux x86)
Created attachment 52275 [details] .log (Windows XP)
Retarget to 4.4. This is a blocker to the adoption of the new AC's backwards compatibility on Linux (125103).
(In reply to comment #6) > Retarget to 4.4. This is a blocker to the adoption of the new AC's backwards > compatibility on Linux (125103). Karla/Kevin, we have seen this behaviour on Windows (XP -> XP) - see comment #3. This should be fixed in 4.3 i3
I resolved a number of non-target specific issues when attempting to solve the linux security problems. They dealt with some race condtions among the threads used for security. I believe they will resolve this issue on windows. When you say XP->XP ... I assume you mean that only the remote case is failing... I this the case? (I'm sure I have tested both cases in the past but its possible that the remote case was overlooked, since this is a case where only the first connect fails)
(In reply to comment #8) Yes, we have seen this behavior in the remote case between Windows XP -> Windows XP.
I have been unable to get this to fail for the 1009 build. The test case I am using is remote profile using secure AC. I am not doubting that you are seeing a failure... this just make verifying my fixes problematic.
Have you tried just the simple case - test connection? It seemed to be consistent in the TPTP-4.3.0-200610160100 build.
I did try "Test Connection" ... I did see a case where the very first connection seemed to fail... but I tried this with a number of new AC executable runs and I was not able to duplicate the failure.
Created attachment 52872 [details] security fix This attachment contains a zip file... the zip files contains 1 dll that I beleive will fix the security bug you are seeing. Extract into AC/bin (WinXP only)
(In reply to comment #13) > Created an attachment (id=52872) [edit] > security fix > This attachment contains a zip file... the zip files contains 1 dll that I > beleive will fix the security bug you are seeing. > Extract into AC/bin (WinXP only) So the IWAT0016E error message does not appear in the local scenario (Windows XP), however, I get the following exception when testing a connection using a fresh workspace: java.lang.NullPointerException at org.eclipse.hyades.internal.execution.security.User.login(User.java:113) at org.eclipse.hyades.internal.execution.local.control.NodeImpl.authenticateUser(NodeImpl.java:512) at org.eclipse.hyades.security.internal.util.BaseConnectUtil.authenticateUser(BaseConnectUtil.java:631) at org.eclipse.hyades.security.internal.util.ConnectUtilUI.promptAuthentication(ConnectUtilUI.java:146) at org.eclipse.hyades.security.internal.util.BaseConnectUtil.promptAuthentication(BaseConnectUtil.java:256) at org.eclipse.hyades.security.internal.util.BaseConnectUtil.connect(BaseConnectUtil.java:240) at org.eclipse.hyades.security.internal.util.BaseConnectUtil.connect(BaseConnectUtil.java:538) at org.eclipse.hyades.security.internal.util.BaseConnectUtil.connect(BaseConnectUtil.java:199) at org.eclipse.hyades.trace.ui.HyadesUtil.testConnection(HyadesUtil.java:599) at org.eclipse.hyades.trace.ui.internal.core.TraceHostUI$1.run(TraceHostUI.java:576) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.hyades.trace.ui.internal.core.TraceHostUI.testConnection(TraceHostUI.java:502) at org.eclipse.hyades.trace.ui.internal.core.TraceHostUI.widgetSelected(TraceHostUI.java:743) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.ui.internal.OpenPreferencesAction.run(OpenPreferencesAction.java:65) at org.eclipse.jface.action.Action.runWithEvent(Action.java:499) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:539) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) Testing the connection again with the same user name and password works.
(In reply to comment #14) BTW, I was using the TPTP-4.3.0-200610240100 driver with the Agent Controller patched with your DLL.
yes... I see that exception in my log file as well... I have done a number of test connects... but yet only see a single exception... this must be from the failure that I noted. are you seeing consistent first connect failure?
Resetting target to 4.3i3 as this issue is found on Windows. Kevin - this bug is not on the list I sent for approval to the PMC list. Once a fix is found/confirmed we'll ask for approval.
(In reply to comment #16) > yes... I see that exception in my log file as well... I have done a number > of test connects... but yet only see a single exception... this must be from > the failure that I noted. > are you seeing consistent first connect failure? Yes.
The fix I was suggesting for this bug is platform independent. For linux it removes the seg-fault, but there are still some new AC issues when security is enabled. When I use my fix I get by the seg-fault but threads produced quickly consume 100% of the CPU. Using the IBM jdk this causes a heap stack overflow. Jrockit does not have the heap overflow but the java threads seem to consuming an awful large amount of cycles considering they should nly being doing an accept on a socket. Again, we still have new AC security issues, I'm just trying to update the bug with what I have seen. This needs further investigation! For windows I have only seen security fail once. (In many attempts)
Closing bug... I have not been able to reproduce this since I updated my fix. Paul said to close the bug and he will verify the build and reopen if he has any issues.
Verified in TPTP-4.3.0-200611070100. Closing.
