How to "Smoke Test" the new technology agent controller

TPTP Wiki home > Miscellaneous >

Our intent is to help someone who finds that they need to "smoke test" the new technology agent controller for the first time. It is not our intent to stifle creativity or define "the one true way"... we're merely trying to document one way that works. In reality, our best bug finds have come when we had someone new "do it their way".

Download the agntctrl and sdk packages for each given system, create subdirectories for holding the release packages, and unzip them there.

There is some debate about whether to overlay the runtime and sdk packages or keep them separate. My fear with overlaying is that you're likely to miss any error in either package if it is masked by the other. Therefore, I put the agntctrl package in <ac> and the sdk package in <sdk>.

Set up environment variables.

{At the Linux shell, or in a CygWin window for Windows}
1. cd <ac>/lib; export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH {Linux only}
2. cd <ac>/bin; export PATH=`pwd`:$PATH
3. export PATH=<path to the correct Java bin>:$PATH

Note that "the correct Java" is something to think carefully about! It's an important factor to document to ensure thorough testing.

Note that if you're running 32-bit apps on a 64-bit system, you're in for a rough ride separating out the two environments!

Set up your <ac>/config/serviceconfig.xml file

It's empty on delivery, so configure by running ./SetConfig.sh {for Linux; cmd SetConfig for Windows} (you are still in the <ac>/bin directory, right?). You can accept defaults for all values (unless you know you want to test security, or remotely from another system, etc.).

Edit the <ac>/agents/*/agent.xml files. {Linux only}

Remove all ".\" prefixes and ".exe" suffixes from all launchinfo lines.

Make sure an AC is not running already:

{Linux}
1. ps aex | grep -i server
2. ls -last /tmp/IBMRAC (clean it out if stuff is there)
3. ipcs (to see if there are unattached shmids! if so, su to root and ipcrm the shmids)

{Windows can utilize the Task Manager to make sure none of the processes are running.}

Start the agent controller.

It's important to use the ACStart.sh script now. {Linux}

Just use ./ACServer. {Windows}

Check the AC for minimal functionality.

Run "./SampleClient". {Windows you'll need another CygWin shell window since the ACServer ties up the other one}

Here's a sample output... YMMV [in what ways can it vary and still be considered successful?]:

Connected to the Agent Controller on "localhost" at port number 10006

The Time Collector Agent ID: 103

Established a data channel with the agent.

Sending 5 Hello messages over data channel to TimeCollector ...

Start the TimeCollector ...


Stop the TimeCollector ...

Incoming data: Hello from Time Collector Agent - Count 0

Incoming data: Hello from Time Collector Agent - Count 1

Incoming data: Hello from Time Collector Agent - Count 2

Incoming data: Hello from Time Collector Agent - Count 3

Incoming data: Hello from Time Collector Agent - Count 4

Incoming data: Hello from Time Collector Agent - Count 5

Incoming data: Hello from Time Collector Agent - Count 6

Incoming data: Hello from Time Collector Agent - Count 7

Incoming data: Hello from Time Collector Agent - Count 8

Incoming data: Hello from Time Collector Agent - Count 9

All finished
Press any key to exit...

Now we're ready to actually use the SDK package to do the three C++ smoke tests.

For each of the sample test directories ConsoleTestClient (and its helper directory SimpleAppl), SampleClient (and its helper directory TimeCollector), and MyFileTransferClient,

{Linux}
1. cd <to the directory>
2. make -f *.make
3. Run each.

{Windows-IA32 will need to utilize MSVC6 to open one of the .dsp files which will create a default workspace. Then each of the other .dsp project specifications can be imported into the workspace. Then set each project and Rebuild all in turn.}

{Windows-EM64T and Windows-IPF don't have MSVC6, so you'll need to open up the appropriate Platform SDK 64-bit Release build environment command prompt. From there go into each of the directories and 'nmake CFG="[ConsoleTestClient | MyFileTransferClient | SampleClient | SimpleAppl | TimeCollector] - [IA64 | X64] Release" -f <project>.mak64'.}

(I'm assuming that the samples under the Compatibility directory are not a part of the smoke testing!)

Note that they're copied into the <sdk>/bin directory upon successful compilation by default.

Also note that if the <sdk> and the <ac> are different directories, and you started the AC without having <sdk>/bin on the PATH, you'll need to copy (at least) the SimpleAppl executable over to <ac>/bin before running the ConsoleTestClient. This is because "./" is interpreted in the ac.launch("./SimpleAppl") statement as relative to the AC launch, not the ConsoleTestClient itself.

Also note that unless you explicitly execute the SampleClient you compiled and explicitly make sure the TimeCollector the AC sees is the one you compiled (by replacing the one in <ac>/bin with the one you compiled), you're not really testing your ability to build and run the SDK code.

Finally note that you will need to have a file called {Windows} "C:\big_simple.txt" {Linux} "/tmp/big_simple.txt" pre-existent before running the MyFileTransferClient test; subsequent to execution you should find that "big_local.txt" is identical to the original file in the same directory.

Here's some sample output from a ConsoleTestClient run:

Connected to the Agent Controller on "localhost" at port number 10006

Preparing to launch app:"./SimpleAppl"
Incoming data: SimpleWAait fpoprl  fhians starteid.
Expect 3 msgs from stdout, 1 msg from stderr, and 1 msg echoed back from stdin.


sIncoming data: SimpleApp stdohued messatg messe, thean Prgee 0.s
SimpleApp stdout message 1.
SimpleApp stdout message 2.


Incoming data: SimpleApp reading from stdin...


Incoming data: SimpleApp stderr message.


Incoming data: SimpleApp read stdin: This is console input to SimpleAppl.


s any key to exit...
Incoming data: SimpleAppl is finished.

Due to the intermixing of outputs from the test itself and the executable it spawns, you can see a wide variety in test outputs.

Having completed the C++ side of the tests, we turn our attention to the Java side.

1. For Java, we need the "execution framework", which is included as a part of the standard TPTP runtime. Thus we download a TPTP runtime package, and extract out just the org.eclipse.tptp.platform.execution files from the downloaded zip file (that is the beginning of the name... there will probably be version info appended).
2. cd <to the location of the downloaded files>/src
3. javac -classpath ../tptpcore.jar org/eclipse/tptp/platform/execution/samples/SampleClientAC.java
4. java -classpath ../tptpcore.jar org/eclipse/tptp/platform/execution/samples/SampleClientAC
   

Output should look something like:

Connecting to Host localhost
Connecting to AC..
Connected to localhost at port number 10006






The Data received from TimeCollector - Hello from Time Collector Agent - Count 0
The Data received from TimeCollector - Hello from Time Collector Agent - Count 1
The Data received from TimeCollector - Hello from Time Collector Agent - Count 2
The Data received from TimeCollector - Hello from Time Collector Agent - Count 3
The Data received from TimeCollector - Hello from Time Collector Agent - Count 4
The Data received from TimeCollector - Hello from Time Collector Agent - Count 5
The Data received from TimeCollector - Hello from Time Collector Agent - Count 6
The Data received from TimeCollector - Hello from Time Collector Agent - Count 7
The Data received from TimeCollector - Hello from Time Collector Agent - Count 8
The Data received from TimeCollector - Hello from Time Collector Agent - Count 9
The Data received from TimeCollector - Hello from Time Collector Agent - Count 10
The Data received from TimeCollector - Hello from Time Collector Agent - Count 11
The Data received from TimeCollector - Hello from Time Collector Agent - Count 12
The Data received from TimeCollector - Hello from Time Collector Agent - Count 13
The Data received from TimeCollector - Hello from Time Collector Agent - Count 14
The Data received from TimeCollector - Hello from Time Collector Agent - Count 15
The Data received from TimeCollector - Hello from Time Collector Agent - Count 16
The Data received from TimeCollector - Hello from Time Collector Agent - Count 17
Data Processor Waiting for Data Called

Now follow the above steps for TPTPProcess.java as well.

Before following the above steps for the SampleFileTransferAC.java test, you'll need to "condition" the test as follows for Linux smoke testing:

• Change all "C:" to "/tmp"
• Change all "\\" to "/"

You'll also need to make sure you have all "the right files" in place prior to running the test. That includes

• /tmp/big_simple.txt -- ASCII file exact multiple of 512 bytes
• /tmp/temp/test.zip -- binary file; I use a zip file
• /tmp/small.txt -- ASCII file less than a block in size
• /tmp/empty.foo -- an empty file
• Optionally, you can hava a /tmp/temp/test2.zip file
  1. With it there, you're testing deleteFile of a file
  2. With it not there, you're testing the case of trying to delete a missing file (also a valid test case!)

When the test is completed, make sure that in /tmp:

• big_simple.txt, big_dupe1.txt, and big_dupe2.txt are all identical files
• temp/test.zip is identical to put_dupe3.zip
• <TT>small.txt and put_dupe4.txt are identical
• put_dupe5.foo is empty
• there is no temp/test2.zip file

Note that the SempleFileTransferAC test loops forever after it does its thing; you'll have to Control-C out of it after the deleteFile is done.

Clean up.

Shut down the agent controller by running "./ACStop.sh".

If you want to make sure shared memory is cleaned up, you might find this useful: for i in `ipcs -m | cut -f 2 -d" "`; do ipcrm shm $i; done