content_image/975999.jpg
We describe some of the methods inside the AME main loop that is shown in Figure 2-13 on page 197: 

GLYPH<SM590000> doXML() 

At startup, the AME thread runs the doXML()  method. The .xml  config file is parsed for defined applications. If no applications are defined, the thread goes to sleep from which it can return by receiving a sync notification from ksysvmmgr . In such a situation, it parses the .xml  file again and looks for defined applications. 

If defined applications are found in the .xml  file, then some memory data structures, which are called maps , are populated or updated with configuration and status details about each found application as follows: 

– If no entries exist in the memory maps for an application, then they are created. 

– If entries exist, then they are updated as derived from the counterpart attributes that are retrieved from the .xml  file in case they are different. 

After reaching this point, the thread returns from doXML()  and calls doLaunch() . 

GLYPH<SM590000> doLaunch() 

For each app in the app map, check the state and decide whether the mon, stop, or start script must be started. If yes, start it and update the maps. Compute the time of the timeout  and update map  entries. After reaching this point, the thread returns from doLaunch()  and calls doNonBlockingWait() . 

GLYPH<SM590000> doNonBlockingWait() 

For each app, look for children processes (started scripts that are not marked as returned yet) and check whether they exited or not. For those that returned, update the states. 

GLYPH<SM590000> doInspectForTimeout() 

For each app, if a timeout condition is ascertained on the current running script, the blocking script is killed and the application status updates. 

Similarly, putting together all noticed state transitions of our test application in the presented scenarios, we come up with the state machine diagram in Figure 2-14. 

<img src='content_image/975999.jpg'>

