Once you understand The Shadow of multi-tasking
then you know that multi-tasking is a beast.

(Click for full image)

Tymeac Tames the Beast

 

The Questions

So, you started a new task to format data into a structure. Where is the structure?

When things go wrong you could always place error messages inside the structure, but what happens if the user cannot locate the structure at all?

A task is another process and when things go wrong, processes need to notify each other or at least have a way to log the errors.

But what if the task logic has a bug and the code loops indefinitely? Now you're in trouble.

How Tymeac handles this.

So, you started a new task to format data into a structure as an autonomous process. Where is the structure?

When things go wrong in autonomous processes (i.e. you place the request in a Queue and you do not wait for it to complete) how are you ever going to find out what happened?

How Tymeac handles this.

So, you started a new task to format data into a structure. Everything else on the Box is now running at a snail pace and where is the structure?

This may be the task overload problem. There may not be enough resources to sustain any more tasks. Every system has a physical and/or practical limit on processes and storage. Then there could be so many other tasks executing and holding locks that nothing is getting done.

This may also be caused by excessive create/destroy overhead. Creating a new task is no small event.

How Tymeac handles this.

So, you started a new task to format data into a structure. Oops, you now decide you want to cancel that task.

Good luck. How in the world are you going to find that task and tell it to stop?

How Tymeac handles this.

So, you started a new task to format data into a structure. What you really need is to format multiple data sources and to put the results into multiple structures.

Either you are going to have one very large program doing multiple functions or multiple tasks for each function. In either case it is going to be a nightmare to control and maintain.

How Tymeac handles this.

So, you started a new task to format data into a structure. What you really need is to reuse some data from a prior request to add to the current request.

The word is persistence. How can you share storage between tasks and requests without using temporary files?

How Tymeac handles this.

So, you started a new task to format data into a structure. Now you find that this process needs recursion (calling itself in a new task.)

This can easily lead to a task overload problem. Just how many levels of recursion should you support?

How Tymeac handles this.

So, you created a server with a nice pool of tasks to handle requests. How can you inquire about the overall health of the server and pinpoint congestion?

Solving this problem requires a ton of code on your part to access storage shared between the tasks and the base server. It also requires User Interfaces to present this picture to the user.

How Tymeac handles this.

So, you created a server with a nice pool of tasks to handle requests. How can you quiesce and shut down gracefully?

If you just terminate the server you could loose the in progress work so it is advisable to quiet the server before shutting it down.

How Tymeac handles this.

So, you created a server with a nice pool of tasks to handle requests and now you need a hot fix to one of them. Does this mean you have to shut down everything and start all over?

Who ever heard of a 24/7 mission-critical server going to sleep much less having to be reborn just to change a light bulb?

How Tymeac handles this.

So, you created a server with a nice pool of tasks to handle requests. How can you debug this multi-tasking application?

One task at a time is easy. Even trapping a method in a task is the mainstay of every debugging product.

What happens when you have many requests hitting the box and storage is getting tight and the problem is intermittent and you're running out of time, etc.?

How Tymeac handles this.

How can you tune the applications on this box?

You must be kidding? You don't even know how many tasks are running at any one time much less the current stage of processing of each individual task.

How Tymeac handles this.

---

How Tymeac handles these problems.

Where is the structure?

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.

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.

Task overload.

Tymeac lets you limit the number of tasks in each Queue. This way you always know the maximum number of tasks that may exist at any one time.

Tymeac puts all requests in prioritized Wait Lists and lets the tasks on the Queue process requests from these Wait Lists. Something like a task pool but with proper management.

Tymeac only creates a task when it is absolutely necessary. This is something no task pool can do. Tymeac uses Thresholds to determine when to create a new task. This way there is no excessive create overhead.

Tymeac reuses tasks when the work finishes rather than destroying the task. This cuts down on the create/destroy overhead.

Components

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 tasks.

Persistence

Tymeac is a Server. The Server itself is persistent. Therefore, maintaining persistent application storage is possible with the use of the user exit structure.

Stalls.

When task hang, abnormally terminate or are unresponsive in autonomous processes this is called a stall. Tymeac handles the stall.

Cancel Requests.

Tymeac allows both synchronous and asynchronous canceling of requests. Tymeac is a mission-critical, professional product.

Recursion

Tymeac supports any level of recursion by letting any Processing Application Program call the Server for a new request. Simply because the call is a new request there is no need for "special code" or limitation.

Picture

Tymeac provides User Interfaces for the following run time functionality:

• Task 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

Shut Down

Tymeac shuts down in multiple stages.

Hot fix.

Tymeac lets you change the Processing Application Program for any Queue at any time.

Debug

Debugging was a primary consideration during Tymeac design.

Tuning

Tuning starts at the design stage. Tymeac is the result of decades of experience.