A Job (
[a.k.a JobCodeInt in the original paper]
This is the basic unit of execution. It is a Java interface. A class
that implements this interface
should implement the
execute() method. This method identifies the entry point of the code
that needs to be executed remotely.
[a.k.a PseudoRemThr in the original paper]
This is the client part, which accepts instances of IJob
implementations and executes them remotely.
It can operate in two modes
In this mode the caller must wait till the job executes remotely before
control is returned back to caller.
In this mode the control returns immediately to the caller. The
submitted job is queued to be executed remotely.
The caller can register a listener with PRT to receive
notifications of job completions. The async mode uses a thread
pool to execute jobs on various remote hosts..
(aashish.prt.jobrunner.IJobRunner) [a.k.a RunServer in the original
This is a remote RMI object that accepts a job for execution from PRT
and returns the result back to the caller.
It maintains statistics about itself. These statistics are used to
select the best job runner to execute a job on. The process
of selecting a best job runner is detailed here
This is a remote RMI object that maintains a registry of all available
job runners. Job runners register themselves with the
host selector and periodically send updates (statistics) about
themselves to the host selector. These updates act as
heartbeats that also signify that a job runner is alive. Based on these
updates the host selector selects the best host available
for execution. If updates are not received from a job runner for
three consecutive heartbeat intervals, the job runner is
removed from the registry. The job runner is auto registered whenever
next update is received.