Why separate the Endpoint Connection thread from the Application?

(The Endpoint Connection thread may be TCP, HTTP, HTTPS, IIOP or even a local thread.)

• What if the Endpoint Connection thread hangs in a never-ending loop?

The calling thread would also hang and require intervention.

With Tymeac^™
The Endpoint thread can never hang since it is not doing the work.

• What if the Endpoint Connection thread needs a new thread itself?

This is the thread overload problem (i.e. where so many threads are executing that the System cannot sustain anymore threads or these threads cause so much competition for resources that the environment effectively stalls.)

The System may not be able to handle any more threads. (see sidebar)

The thread create/destroy overhead may bog down the application processing.

With Tymeac^™
The Endpoint thread can never need a new thread itself since it is not doing the work.

• What if the Endpoint Connection thread needs timing?

Threads cannot time themselves at the same level. If they hang in a never-ending loop or block then there would be no way to interrupt them. By creating a new timer thread, we run into the problem mentioned above.

With Tymeac^™
The Endpoint thread is already timed.

• What is the status of the current request?

An outside inquiry into the status of a particular request would be very difficult at best. Just trying to locate the thread associated with a particular request would be a major undertaking. Then trying to determine the status thereof would require a mountain of code.

With Tymeac^™
The Endpoint thread doesn't have a status. It is the application that has a status and Tymeac keeps the status of each request both synchronous and autonomous. This means that there is a history for prior requests.

• What is the status of a prior request?

If you thought the above current request was difficult, now add a history.

Tymeac^™
keeps a log. Requests for the status of prior autonomous requests is easy.

• How can others inquire about the overall health of the environment?

This means getting the status of each current request (see above). Then looking at every resource in the system for loading. Then analyzing requests/loading and generating a report.

With Tymeac^™
This is already done.

• Where is the congestion?

What if an application is hitting on some resource beyond what that resource can handle and there is a backlog? The only way to know where the congestion lies is to look at every connection and analyze the processing. That means getting the status of each current request, see above.

Tymeac^™
provides over a dozen GUI and non-GUI methods for users to inquire about the health of their system and to pinpoint congestion.

• How to detect and recover from stalls with autonomous requests (a situation in which a request is unable to complete)?

Timing a request (see above) is the best method to catch the stall except when the request is autonomous. Now there is no Endpoint Connection thread to time. So, here we go again trying to get the status of each current request and determine whether it is able to complete.

Tymeac^™
times the autonomous request so that stalls are detectable and recoverable.

• How to tune this multi-threading environment?

You must be kidding. How would you limit the number of threads for each application? How would you put your resources exactly where they are needed depending on the current load? Perhaps you have the time and energy to tackle these issues.

Tymeac^™
provides administrators the tools necessary to finely tune their systems.

• How may the threading environment quiesce and shut down gracefully?

If you have no effective control over what comes into the system and you have no effective control over the threading environment itself, then your only option for shut down is to end the Java Virtual Machine.

Tymeac^™
provides a two stage shut down with user exits for individual needs.