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.