The hardest part of computer programming is error recovery. How the team handles
anomalies separates the professionals from the amateurs.
Tymeac handles logging of all phases of the Server. You may place the
log in a DBMS, local file or supply your own code to store the messages.
Tymeac notifies system administrators when problems arise in the
Server. You may tailor this to your own specifications.
Tymeac times the application processing so that excessive execution
times can be trapped.
Tymeac handles abnormally ending applications by flagging the
offender as no longer available.
Tymeac lets you limit the number of threads in each Queue. This way you always know the
maximum number of threads that may exist at any one time.
Tymeac puts all requests in prioritized Wait
Lists and lets the threads on the Queue process requests from these Wait
Lists. Something like a thread pool but with proper management.
Tymeac only creates a thread when it is absolutely necessary. This is something no
thread pool can do. Tymeac uses Thresholds
to determine when to create a new thread. This way there is no excessive create overhead.
Tymeac reuses threads when the work finishes rather than destroying the thread. This
cuts down on the create/destroy overhead. (See these parameters: idle wait time and idle thread life).
Tymeac is a request broker. Tymeac supports multiple functionality
(components) within a request by placing each component in a separate
Queue with its own set of threads.
Tymeac is a Server, both RMI and internal. The Server itself is
persistent. Therefore, maintaining persistent application storage is
possible with the use of the user exit structure.
When threads hang, abnormally terminate or are unresponsive in autonomous processes
this is called a stall. Tymeac handles the stall.
Tymeac allows both synchronous and asynchronous canceling of
requests. Tymeac is a mission-critical, professional product.
Tymeac supports any level of recursion by letting any Processing
Application Class call the Server for a new request. Simply because the
call is a new request there is no need for "special code" or limitation.
Tymeac provides GUI clients for the following run time
- Thread status/alteration
- Wait List status/alteration
- Stalled asynchronous request display/alteration
- Live Queue modification
- Live Function statistics
- System statistics snap shot
- Asynchronous request status/cancellation
- Hot fix to a user application Class
- Overall system picture
- System shut down
Tymeac provides non-GUI clients for the above so that users can fetch the raw data and
easily make use of it.
Tymeac shuts down in multiple stages.
Tymeac lets you change the Processing Application Class for any Queue
at any time.
Debugging was a primary consideration during Tymeac design.
Tuning starts at the design stage. Tymeac is the result of decades of