PID management

This document summarizes the PID controlling of the demo system.
Previous Design:
The ProcessManager called a shell script with the java equivalent of system("/bin/sh script.sh") so the ProcessManager did not have a direct method of knowing the server PIDs. The problem was solved by having an initial PID-request packet sent to each server of the demo. The resulting packets containing the PID were collected by the client and sent using the DemoProtocol interaction between the ConnectionManager and ProcessManager. This process had many points of failure. Another downfall was if the Communicator hub failed to start, then the demo would never start and the ProcessManager would have no way of knowing the server's PIDs. Upon ending of the demo, the ISIP-Communicator servers would remain executing with no method of killing them.
Summary of Process ID Management:
The java ProcessManager parses the shell-script and places the hub and each server in its own "ProcessAndOutput" (PaO) object which has encapsulates a Process object and the Stdout\Stderr output. A GroupRunner object holds all of these PaOs and polls each every 5 seconds to verify none have exited. If the hub or any server has exited, all the PaOs are killed and a error message is sent to the client with a disconnect request.
Description of Process ID Management:
- Background:
  Java contains a Process object which allows a Java program to control another process. Since the ProcessManager is written in Java, each the hub and servers can be within their own Process. This allows the ProcessManager to control each demo's hub and servers to be independently.
- Process:
  The client and server communicate through the DemoProtocol and determine the type of demo to be started. (See the DemoProtocol Info for more information). Once the ProcessManager gets the MSG_START_DEMO signal, the ProcessManager performs the following.
  1) Strips commends, empty lines, and any '&' symbols out of the lines.
  2) Replaces environment variables in each line with the respective value (such as $ISIP_TMPDIR or $GC_HOME).
  3) Parses the line into the executable and the, potentially not present, log file.
  Note: Since redirection can get confusing, the only redirection allowed is a single redirection of stdout to a file.
  Allowed: /bin/hub -verbose
  Allowed: /bin/hub -verbose > /tmp/hub_log.txt
  Allowed: /bin/hub -verbose 1> /tmp/hub_log.txt
  NOT Allowed: /bin/hub -verbose 2> /tmp/hub_err.txt
  NOT Allowed: /bin/hub -verbose 1> /tmp/hub_log.txt 2> /tmp/hub_err.txt
  NOT Allowed: /bin/hub -verbose > /tmp/hub_log.txt 2> /tmp/hub_err.txt
  Therefore the line is parsed into two pieces.
  The first piece being everything up to the ">" which is designated as the executable and the rest of the line after ">" is the stdout log.
  4) Passes these two pieces of information to the GroupRunner (GR) object. Note: The process is the same for the hub and the servers. The text "/bin/hub" being present is what determines if it the hub.
  4a) The GroupRunner object creates a ProcessAndOutput (PaO) object with the data and stores this PaO in a vector.
  5) Executes GroupRunner.startAllServers() upon completion of parsing the shell script.
  The ProcessManager gives thread control to the GroupRunner and the GR traverses the PaO vector and calls PaO.startRunning(). Each PaO.startRunning() command performs the following.
  1) Starts the executable as a Process and stores the object as member data.
  2) Retreives the stdout and stderr streams and stores them as member data.
  3) Determines if the stdout stream needs to be redirected to a file and creates said output file.
  4) Creates a thread that both monitors the stdout and stderr streams for data and prints the data to the respective output location.
  Once the GR completes starting all the PaOs, the GR creates a monitoring thread that polls all the PaOs every 5 seconds to determine if any have exited. During startAllServers() or PaO polling, if the GR determines any PaO has exited, all PaOs are forcefully terminated, and a message is sent to the client using the DemoProtocol notifying the client of an error.
- Class Hierachy:
  ProcessAndOutput implements Runnable
  - defined within the DemoClientHandler
  - contains a Process object
  - contains a BufferedReader for stdout
  - contains a BufferedReader for stderr
  - is a thread that polls the stdout\stderr streams for data
  GroupRunner implements Runnable
  - defined within the DemoClientHandler
  - contains a vector of ProcessAndOutputs
  - is a thread that polls previous-mentioned vector
  DemoClientHandler implements DemoProtocol
  - contains a GroupRunner object
  - contains definition of ProcessAndOutput
  - contains definition of GroupRunner
- Other facts:
  - All the PID controlling information is all done in the DemoClientHandler.java file of the isip_comm_server_process_manager, totally independent of the client.
  - The hub pgm scripts have been edited to just comment out all previous PID interactions. These can be removed without harm to the current setup.
  - All the servers were edited so instead of starting in the GET_PROCESS_ID state, each start in the state after that. Therefore all the servers can be easily changed back to send out the PID, or that code may be removed since it is no longer used in the current setup.