Tymeac Monitor

Tymeac is a pure application. There are no hooks, no operating system exits, nor special Java programs. This is in order that Tymeac may run without interfering with any existing exit routine and may run on any future release of RMI without modification.

Without accessing internal Java tables or using operating system exit routines a monitor facility is necessary for the use of asynchronous threads.

Tymeac start-up starts the Monitor Thread when the monitor interval is greater than zero (use zero for testing when you need to trap threads.) The Monitor Thread is compute intensive. The only I/O is for logging messages. When the Monitor finds possible problems it logs messages. Therefore, the interval should be long enough not to interfere with normal execution. We recommend starting this interval at 60 seconds. Your processing requirements determine the final value.

The Monitor Thread examines each Queue. The code uses the Monitor Interval, or, one minute if the interval is less, as the time interval in determining when there may be a problem.

Tymeac keeps track of the time of several events.

The Monitor examines each Wait List entry for a non performing Queue, i.e., no Queue Thread busy, posted, activated, or waiting, and, when an Asynchronous Request, it adds an entry to the Stall Array.

The Monitor purges Synchronous Requests that exceed the wait_time (set in the parameter passed to Tymeac Server) by an excessive amount.

The amount is release dependent. However, it is always several times the wait_time parameter, or, twice the Monitor interval, whichever is greater.

The logic here is that the caller is only willing to wait for the wait_time. Anything that happens thereafter is no longer relevant to the caller. Since the request is irrelevant, off with its head.

Since there is a delay in purging a timed-out request, one may see the count of synchronous requests greater then those actually present in the system when viewing the overall Tymeac environment, TyOverall.

The Monitor purges Asynchronous Requests that were possibly stalled and then finished.

See here for more detail on this.

The Monitor also purges requests that were cancelled but some Queues were still executing at the time of the cancel.

These may be both Synchronous or Asynchronous requests. For instance, you cancel a request with three queues.

Queue-1 already completed.

Queue-2 is executing.

Queue-3 hasn't started and Tymeac removes the request from that queue.

Since one Queues is busy, Tymeac cannot free the resources until that executing Queue finishes. The Queue Thread itself will try to free the resources when it finishes, but this doesn't always happen. Hence, the Monitor to the rescue.

The Monitor handles the de-activation procedure for an Activatable Server.

You simply cannot run without the Monitor Thread in a production environment.

When things go wrong or when requests time-out or are cancelled it is the Monitor Thread that cleans up the environment.

Therefore, the Monitor Thread has an uncaught exception handler that shuts down Tymeac when invoked. The handler tries several times to shut down normally, then forces shut down. (See the shut down document for shut down details.)

Details

Tymeac performs two important services as a Backend Server:

memory management and
thread management.

Memory management

When Tymeac receives a new request it must save the parameters of that request for the Queues (basically the input Object from the client.) Tymeac also allocates resources to keep track of the progress of the request. Tymeac saves the output Objects from the Queues to return to the requester (synchronous request) or to pass on to the Output Agent (asynchronous request.)

Normally, the End-Point Connection thread^[1]handles the allocation of resources.

For synchronous requests this thread also handles the freeing of resources (making available to the garbage collector.)

However, when a synchronous request times-out or is cancelled the following occurs:

Tymeac attempts to back out^[2] all the Queues that have not finished processing.

Tymeac forms a return Object array containing the Objects from the completed Queues.

All the resources (Tymeac storage, client input Object, Queue output Objects) remain in case a currently executing Queue Thread needs access to any resource.

It is the Monitor that eventually cleans up this storage.

For asynchronous requests the last Queue Thread to finish in the request handles the freeing of resources (making available to the garbage collector.)

However, when an asynchronous request fails scheduling or stalls, the resources remain. See the Stall Array.

Once again, it is the Monitor that eventually cleans up this storage.

Thread management

Multi-threading is a potential nightmare. The only truly effective way to control a thread of execution is at the operating system level. Time slicing, preempting, prioritizing, recognizing the stall, etc. -- these functions are most difficult to control at the thread level.

In an applet or GUI application multi-threading is both easy and safe. If a thread hangs or misbehaves, simply close the window and start over. Using a separate thread as a listener is preferable.

It is on the server side that multi-threading can get out of control. Threads can hang, abnormally terminate or stall and the client may never know. It is for these reasons that Tymeac times the functions in the life of a thread.

Since Tymeac has no operating system hooks, the next best way to control the threads on a backend Server is with a Monitor^[3] thread.

It is the Monitor that examines the Tymeac threading environment, flags potential problems and notifies users through the Notification Function.

^¹	For the remote server, this is the daemon thread of execution that runs the implementation of the Tymeac Interface. Java creates this thread in response to the RMI request from a client. For the internal server, this is the Client thread.

^²	Back-out occurs when a Queue, within a Function, fails scheduling. The Tymeac Server informs all previously scheduled Queues to ignore processing. If the request is in a Wait List, then Tymeac removes that entry.

^³

The Monitor runs as a non-daemon thread. We see no advantage to daemon since with RMI there are
"keep alive" threads. Additionally,
The non-activatable Servers all issue a never ending wait() to protect resources from garbage collection. The shutRequest() starts the shut down thread which destroys the JVM.
The activatable servers deactivate and destroy the JVM.