The MGS Service
The MGS service will run as a system daemon or service. The MGS service
requires that the RMI Registry is already running and available. The RMI
Registry provides a way for clients to find out where the remote service is
located by looking up the remote service in a registry. This function is
provided by the Java environment; no custom code needs to be developed. The RMI
Registry runs as a separate service on the same server as the MGS Service.
The following sections outline the main methods of the MGS service:
- MGS Service Constructor
- is responsible for initializing all private variables and starting the
thread which processes the incoming messages. Two local variables are important
here; the directory where the MGS files are located - set as a command line
parameter and the time-out value used in the service thread (see the "run"
method below) which is also set via command line parameter. Whenever the
service is started it will call the "cycle_log_file" method so we
start with a brand new MGS log file.
logCommand- is an administrative method, which can be called remotely to cause the MGS
log file to be cycled.
logThis- is the remote method which is called to log an MGS Message. It will
simply add the remote object to an internal queue (stored as a Java Vector) and
return to the calling object.
cycle_log_file- is an internal method which is called by the logCommand, run, and
Constructor methods. Its responsibility is to cycle the MGS log file. The MGS
log filename is four components; the string "mgs" followed by today's
date, followed by a version number (zero is always the active file), and finally
appended by the ".log" postfix. For example an MGS log file would
look like "mgs061497v00.log". There may be several versions in a day,
if the service is restarted frequently.
run- is the child thread which actually writes the MGS Message out to the log
file. This thread runs in a continual loop looking for messages to process. If
a message is available to be processed, it will check the current date. If it
has changed it will call the "cycle_log_file" method to get a new MGS
log file, the MGS log file is opened in append mode, the message is retrieved
from the queue, written to the file, and finally removed from the queue. The
thread will continue to process messages until there are no more messages. The
thread will then sleep for the time period specified by the time-out attribute
set in the MGS Service Constructor, before checking the queue for more messages.
main- is responsible for creating the MGS Service and binding it with the RMI
Registry.
|
