Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Test and Performance Tools Platform (TPTP) » Unable to get agent to register with NT AC
Unable to get agent to register with NT AC [message #72131] Mon, 29 May 2006 17:35 Go to next message
Michael Iles is currently offline Michael IlesFriend
Messages: 7
Registered: July 2009
Junior Member
I'm trying to write an agent to register with the new technology agent
controller, and am having trouble.

The 'SampleClient.exe' example works fine.

I'm running the NT AC from development build TPTP-4.2.0-200605251528.

I'm working with the TPTPJavaAgent class, as well as a simple agent of
my own that extends
org.eclipse.tptp.platform.execution.datacollection.BaseAgent .

The behaviour I see is that during the agent's registration with the AC,
the call into the native method BaseAgent.register0 blocks.

My next step is probably to build the DLLs myself to get symbols, but do
people have any suggestions? Are native symbols available for the DLLs?
(Is it worth logging a bug to get the symbols included in the SDK packages?)

Any advice appreciated,
Mike.

--

Just in case it's helpful, here are the two native call stacks from the
blocked agent process that involve the TPTP agent libraries:

0c43df58 7c802542 ntdll!KiFastSystemCallRet
0c43df6c 0bb91a7a kernel32!WaitForSingleObject+0x12
0c43df90 0bb71fc8 transportSupport!connectToNamedPipe+0x6a
0c43df94 0c3000ec AgentBase!BaseAgentImpl::handleMessages+0x88
0c43df98 0bc701a0 0xc3000ec
0c43df9c 00390008 0xbc701a0
0c43dfa0 77e462c0 0x390008
0c43dfa4 0c43ffec ADVAPI32!ElfFlushEventLog+0xd9e7
0c43dfa8 0c3000d8 0xc43ffec
0c43ffec 00000000 0xc3000d8

and

0b36b3fc 7c802542 ntdll!KiFastSystemCallRet
0b36b410 0bba7177 kernel32!WaitForSingleObject+0x12
0b36b41c 0bb7188d tptpUtils!tptp_waitSemaphore+0x17
0b36b4e8 6d6b1600 AgentBase!BaseAgentImpl::registerAgent+0x21d
0b36b4ec 65736142 jvm+0x41600
0b36b4f0 6e656741 0x65736142
....
Re: Unable to get agent to register with NT AC [message #72508 is a reply to message #72131] Wed, 31 May 2006 16:25 Go to previous messageGo to next message
Andy Kaylor is currently offline Andy KaylorFriend
Messages: 23
Registered: July 2009
Junior Member
Hi Michael,

Just looking at the call stacks, it looks like the agent has written
something to the AC's named pipe and is waiting for the AC to open the
agent's named pipe and write a response.

The thing I would do is modify your serviceconfig.xml file to set the
logging level to DEBUG (it is INFORMATION by default), and then look at the
output to see what the AC says has happened. If it received the agent's
command, it will have written something in the log saying what it did.

-Andy


"Michael Iles" <michael.iles@cognos.com> wrote in message
news:e5fbd4$f2o$1@utils.eclipse.org...
> I'm trying to write an agent to register with the new technology agent
> controller, and am having trouble.
>
> The 'SampleClient.exe' example works fine.
>
> I'm running the NT AC from development build TPTP-4.2.0-200605251528.
>
> I'm working with the TPTPJavaAgent class, as well as a simple agent of my
> own that extends
> org.eclipse.tptp.platform.execution.datacollection.BaseAgent .
>
> The behaviour I see is that during the agent's registration with the AC,
> the call into the native method BaseAgent.register0 blocks.
>
> My next step is probably to build the DLLs myself to get symbols, but do
> people have any suggestions? Are native symbols available for the DLLs?
> (Is it worth logging a bug to get the symbols included in the SDK
> packages?)
>
> Any advice appreciated,
> Mike.
>
> --
>
> Just in case it's helpful, here are the two native call stacks from the
> blocked agent process that involve the TPTP agent libraries:
>
> 0c43df58 7c802542 ntdll!KiFastSystemCallRet
> 0c43df6c 0bb91a7a kernel32!WaitForSingleObject+0x12
> 0c43df90 0bb71fc8 transportSupport!connectToNamedPipe+0x6a
> 0c43df94 0c3000ec AgentBase!BaseAgentImpl::handleMessages+0x88
> 0c43df98 0bc701a0 0xc3000ec
> 0c43df9c 00390008 0xbc701a0
> 0c43dfa0 77e462c0 0x390008
> 0c43dfa4 0c43ffec ADVAPI32!ElfFlushEventLog+0xd9e7
> 0c43dfa8 0c3000d8 0xc43ffec
> 0c43ffec 00000000 0xc3000d8
>
> and
>
> 0b36b3fc 7c802542 ntdll!KiFastSystemCallRet
> 0b36b410 0bba7177 kernel32!WaitForSingleObject+0x12
> 0b36b41c 0bb7188d tptpUtils!tptp_waitSemaphore+0x17
> 0b36b4e8 6d6b1600 AgentBase!BaseAgentImpl::registerAgent+0x21d
> 0b36b4ec 65736142 jvm+0x41600
> 0b36b4f0 6e656741 0x65736142
> ...
>
>
>
Re: Unable to get agent to register with NT AC [message #72755 is a reply to message #72508] Wed, 31 May 2006 18:32 Go to previous messageGo to next message
Michael Iles is currently offline Michael IlesFriend
Messages: 7
Registered: July 2009
Junior Member
I ended up debugging this and found that the agent's 'connect' message
was being ignored by the AC because the magic numbers used in the
message header didn't match: the AC was expecting 0x82656780
(platform/org.eclipse.tptp.platform.agentcontroller/src-nati ve-new/src/transport/TPTPAgentCompTL/ACTLServer.c:491)
but the agent was sending 0x54B674DE
(platform/org.eclipse.tptp.platform.agentcontroller/src-nati ve-new/include/tptp/TPTPMessageHeader.h:62).

I logged bug 144536 for this and Guru has indicated that it's a known
problem (bug 135919).

Mike.


Andy Kaylor wrote:
> Hi Michael,
>
> Just looking at the call stacks, it looks like the agent has written
> something to the AC's named pipe and is waiting for the AC to open the
> agent's named pipe and write a response.
>
> The thing I would do is modify your serviceconfig.xml file to set the
> logging level to DEBUG (it is INFORMATION by default), and then look at the
> output to see what the AC says has happened. If it received the agent's
> command, it will have written something in the log saying what it did.
>
> -Andy
>
>
> "Michael Iles" <michael.iles@cognos.com> wrote in message
> news:e5fbd4$f2o$1@utils.eclipse.org...
>> I'm trying to write an agent to register with the new technology agent
>> controller, and am having trouble.
>>
>> The 'SampleClient.exe' example works fine.
>>
>> I'm running the NT AC from development build TPTP-4.2.0-200605251528.
>>
>> I'm working with the TPTPJavaAgent class, as well as a simple agent of my
>> own that extends
>> org.eclipse.tptp.platform.execution.datacollection.BaseAgent .
>>
>> The behaviour I see is that during the agent's registration with the AC,
>> the call into the native method BaseAgent.register0 blocks.
>>
>> My next step is probably to build the DLLs myself to get symbols, but do
>> people have any suggestions? Are native symbols available for the DLLs?
>> (Is it worth logging a bug to get the symbols included in the SDK
>> packages?)
>>
>> Any advice appreciated,
>> Mike.
>>
>> --
>>
>> Just in case it's helpful, here are the two native call stacks from the
>> blocked agent process that involve the TPTP agent libraries:
>>
>> 0c43df58 7c802542 ntdll!KiFastSystemCallRet
>> 0c43df6c 0bb91a7a kernel32!WaitForSingleObject+0x12
>> 0c43df90 0bb71fc8 transportSupport!connectToNamedPipe+0x6a
>> 0c43df94 0c3000ec AgentBase!BaseAgentImpl::handleMessages+0x88
>> 0c43df98 0bc701a0 0xc3000ec
>> 0c43df9c 00390008 0xbc701a0
>> 0c43dfa0 77e462c0 0x390008
>> 0c43dfa4 0c43ffec ADVAPI32!ElfFlushEventLog+0xd9e7
>> 0c43dfa8 0c3000d8 0xc43ffec
>> 0c43ffec 00000000 0xc3000d8
>>
>> and
>>
>> 0b36b3fc 7c802542 ntdll!KiFastSystemCallRet
>> 0b36b410 0bba7177 kernel32!WaitForSingleObject+0x12
>> 0b36b41c 0bb7188d tptpUtils!tptp_waitSemaphore+0x17
>> 0b36b4e8 6d6b1600 AgentBase!BaseAgentImpl::registerAgent+0x21d
>> 0b36b4ec 65736142 jvm+0x41600
>> 0b36b4f0 6e656741 0x65736142
>> ...
>>
>>
>>
>
>
Re: Unable to get agent to register with NT AC [message #72760 is a reply to message #72508] Wed, 31 May 2006 19:07 Go to previous messageGo to next message
Vishnu is currently offline VishnuFriend
Messages: 19
Registered: July 2009
Junior Member
Hi Michael,

I would like you to try one more thing.

In the command shell where you are running the TPTPJavaAgent program, set
the SERVICECONFIG environment variable pointing to the serviceconfig.xml
file, for e.g. as shown below.

set SERVICECONFIG=C:\AC_INSTALL_DIR\config\serviceconfig.xml.

I think, the reason agent is not registering with AC is because it is trying
to connect to the default values of named pipe and shared memory names
('ramaster' and 'rabuffer') and the AC is using 'acmaster' and 'acbuffer'.
So, setting the above environment variable will make the agent read these
values from the serviceconfig.xml file (same as the values AC is running
with).

Please try and let us know.

Thanks
Vishnu

"Andy Kaylor" <andrew.kaylor@intel.com> wrote in message
news:e5kg2r$lk1$1@utils.eclipse.org...
> Hi Michael,
>
> Just looking at the call stacks, it looks like the agent has written
> something to the AC's named pipe and is waiting for the AC to open the
> agent's named pipe and write a response.
>
> The thing I would do is modify your serviceconfig.xml file to set the
> logging level to DEBUG (it is INFORMATION by default), and then look at
> the output to see what the AC says has happened. If it received the
> agent's command, it will have written something in the log saying what it
> did.
>
> -Andy
>
>
> "Michael Iles" <michael.iles@cognos.com> wrote in message
> news:e5fbd4$f2o$1@utils.eclipse.org...
>> I'm trying to write an agent to register with the new technology agent
>> controller, and am having trouble.
>>
>> The 'SampleClient.exe' example works fine.
>>
>> I'm running the NT AC from development build TPTP-4.2.0-200605251528.
>>
>> I'm working with the TPTPJavaAgent class, as well as a simple agent of my
>> own that extends
>> org.eclipse.tptp.platform.execution.datacollection.BaseAgent .
>>
>> The behaviour I see is that during the agent's registration with the AC,
>> the call into the native method BaseAgent.register0 blocks.
>>
>> My next step is probably to build the DLLs myself to get symbols, but do
>> people have any suggestions? Are native symbols available for the DLLs?
>> (Is it worth logging a bug to get the symbols included in the SDK
>> packages?)
>>
>> Any advice appreciated,
>> Mike.
>>
>> --
>>
>> Just in case it's helpful, here are the two native call stacks from the
>> blocked agent process that involve the TPTP agent libraries:
>>
>> 0c43df58 7c802542 ntdll!KiFastSystemCallRet
>> 0c43df6c 0bb91a7a kernel32!WaitForSingleObject+0x12
>> 0c43df90 0bb71fc8 transportSupport!connectToNamedPipe+0x6a
>> 0c43df94 0c3000ec AgentBase!BaseAgentImpl::handleMessages+0x88
>> 0c43df98 0bc701a0 0xc3000ec
>> 0c43df9c 00390008 0xbc701a0
>> 0c43dfa0 77e462c0 0x390008
>> 0c43dfa4 0c43ffec ADVAPI32!ElfFlushEventLog+0xd9e7
>> 0c43dfa8 0c3000d8 0xc43ffec
>> 0c43ffec 00000000 0xc3000d8
>>
>> and
>>
>> 0b36b3fc 7c802542 ntdll!KiFastSystemCallRet
>> 0b36b410 0bba7177 kernel32!WaitForSingleObject+0x12
>> 0b36b41c 0bb7188d tptpUtils!tptp_waitSemaphore+0x17
>> 0b36b4e8 6d6b1600 AgentBase!BaseAgentImpl::registerAgent+0x21d
>> 0b36b4ec 65736142 jvm+0x41600
>> 0b36b4f0 6e656741 0x65736142
>> ...
>>
>>
>>
>
>
Re: Unable to get agent to register with NT AC [message #72764 is a reply to message #72760] Wed, 31 May 2006 20:21 Go to previous messageGo to next message
Michael Iles is currently offline Michael IlesFriend
Messages: 7
Registered: July 2009
Junior Member
Vishnu Naikawadi wrote:
> In the command shell where you are running the TPTPJavaAgent program, set
> the SERVICECONFIG environment variable pointing to the serviceconfig.xml
> file, for e.g. as shown below.
>
> set SERVICECONFIG=C:\AC_INSTALL_DIR\config\serviceconfig.xml.
>
> I think, the reason agent is not registering with AC is because it is trying
> to connect to the default values of named pipe and shared memory names
> ('ramaster' and 'rabuffer') and the AC is using 'acmaster' and 'acbuffer'.
> So, setting the above environment variable will make the agent read these
> values from the serviceconfig.xml file (same as the values AC is running
> with).
>
> Please try and let us know.

Hi Vishnu, yes, that works, thanks very much for that. Hopefully others
will take note and not have to repeat this debugging process... :)

Mike.
Re: Unable to get agent to register with NT AC [message #73103 is a reply to message #72764] Fri, 02 June 2006 22:56 Go to previous messageGo to next message
Karla Callaghan is currently offline Karla CallaghanFriend
Messages: 10
Registered: July 2009
Junior Member
When developing agents, it's important that the agent and Agent Controller
(AC) are talking on the same channels. So, I want to clarify what was
happening in case anyone wants to use this thread as a reference.

The agent registration failed because the agent did not find the
serviceconfig.xml file that was being used by the Agent Controller. The
config file tells the agent how to connect to the same transport layers
(named pipe, shared mem) the AC is using. Since the config file was not
found, the agent defaulted to use the wrong names when trying to connect to
the AC and hung. (A similar problem may have occurred if the agent found the
wrong serviceconfig.xml file - that is, one that was different from that
used by the AC when it was started.)

If an agent calls the BaseAgent processCommandLine() method before calling
on registerAgent(), the search for the config file occurs as follows:
First, check the agent's cmdline args for the -serviceconfig option and use
its value as the pathname for the config file. If that cmd line option is
not found, get the env var TPTP_AC_HOME and look in the config directory
found relative to that path (TPTP_AC_HOME/config/serviceconfig.xml). If
that env var is not set, look relative to the location of the agent
(../config/serviceconfig.xml).

If processCommandLine() is not called, the agent will read the env var
SERVICECONFIG to try and locate the serviceconfig.

There are 2 bugs is see in the behavior described, so I added a bugzilla to
go along with the one Guru mentioned:
1) The Java API is missing its processCommandLine method, so a java agent
can't use it.135919
2) The same search path should have been used for finding the config file,
even when processCommandLine() is omitted .145165

Both are expected to be fixed for GA of 4.2.

-Karla

"Michael Iles" <michael.iles@cognos.com> wrote in message
news:e5ktrh$4h8$1@utils.eclipse.org...
> Vishnu Naikawadi wrote:
>> In the command shell where you are running the TPTPJavaAgent program, set
>> the SERVICECONFIG environment variable pointing to the serviceconfig.xml
>> file, for e.g. as shown below.
>>
>> set SERVICECONFIG=C:\AC_INSTALL_DIR\config\serviceconfig.xml.
>>
>> I think, the reason agent is not registering with AC is because it is
>> trying to connect to the default values of named pipe and shared memory
>> names ('ramaster' and 'rabuffer') and the AC is using 'acmaster' and
>> 'acbuffer'. So, setting the above environment variable will make the
>> agent read these values from the serviceconfig.xml file (same as the
>> values AC is running with).
>>
>> Please try and let us know.
>
> Hi Vishnu, yes, that works, thanks very much for that. Hopefully others
> will take note and not have to repeat this debugging process... :)
>
> Mike.
Re: Unable to get agent to register with NT AC [message #73118 is a reply to message #73103] Fri, 02 June 2006 23:02 Go to previous message
Karla Callaghan is currently offline Karla CallaghanFriend
Messages: 10
Registered: July 2009
Junior Member
One more thing. When the fix for bug 145165 is done, the use of env var
SERVICECONFIG will be eliminated.

-Karla

"Karla Callaghan" <karla.callaghan@intel.com> wrote in message
news:e5qfmf$2tk$1@utils.eclipse.org...
> When developing agents, it's important that the agent and Agent Controller
> (AC) are talking on the same channels. So, I want to clarify what was
> happening in case anyone wants to use this thread as a reference.
>
> The agent registration failed because the agent did not find the
> serviceconfig.xml file that was being used by the Agent Controller. The
> config file tells the agent how to connect to the same transport layers
> (named pipe, shared mem) the AC is using. Since the config file was not
> found, the agent defaulted to use the wrong names when trying to connect
> to the AC and hung. (A similar problem may have occurred if the agent
> found the wrong serviceconfig.xml file - that is, one that was different
> from that used by the AC when it was started.)
>
> If an agent calls the BaseAgent processCommandLine() method before calling
> on registerAgent(), the search for the config file occurs as follows:
> First, check the agent's cmdline args for the -serviceconfig option and
> use its value as the pathname for the config file. If that cmd line option
> is not found, get the env var TPTP_AC_HOME and look in the config
> directory found relative to that path
> (TPTP_AC_HOME/config/serviceconfig.xml). If that env var is not set, look
> relative to the location of the agent (../config/serviceconfig.xml).
>
> If processCommandLine() is not called, the agent will read the env var
> SERVICECONFIG to try and locate the serviceconfig.
>
> There are 2 bugs is see in the behavior described, so I added a bugzilla
> to go along with the one Guru mentioned:
> 1) The Java API is missing its processCommandLine method, so a java agent
> can't use it.135919
> 2) The same search path should have been used for finding the config file,
> even when processCommandLine() is omitted .145165
>
> Both are expected to be fixed for GA of 4.2.
>
> -Karla
>
> "Michael Iles" <michael.iles@cognos.com> wrote in message
> news:e5ktrh$4h8$1@utils.eclipse.org...
>> Vishnu Naikawadi wrote:
>>> In the command shell where you are running the TPTPJavaAgent program,
>>> set the SERVICECONFIG environment variable pointing to the
>>> serviceconfig.xml file, for e.g. as shown below.
>>>
>>> set SERVICECONFIG=C:\AC_INSTALL_DIR\config\serviceconfig.xml.
>>>
>>> I think, the reason agent is not registering with AC is because it is
>>> trying to connect to the default values of named pipe and shared memory
>>> names ('ramaster' and 'rabuffer') and the AC is using 'acmaster' and
>>> 'acbuffer'. So, setting the above environment variable will make the
>>> agent read these values from the serviceconfig.xml file (same as the
>>> values AC is running with).
>>>
>>> Please try and let us know.
>>
>> Hi Vishnu, yes, that works, thanks very much for that. Hopefully others
>> will take note and not have to repeat this debugging process... :)
>>
>> Mike.
>
>
Previous Topic:Re: Eclipse on Linux proposal
Next Topic:Does TPTP work on Mac/Intel?
Goto Forum:
  


Current Time: Thu Apr 18 01:02:57 GMT 2024

Powered by FUDForum. Page generated in 0.02281 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top