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

(Click for full image)

Tymeac Tames the Beast

The Questions

So, you started a thread to format data into a local file Where is the file?

When things go wrong you could always place error messages inside the file, but what happens if the user is not authorized to access the file system?

A thread 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 thread logic has a bug and the code loops indefinitely? Now you're in trouble.

How Tymeac handles this.

So, you started a thread to format data into a local file as an autonomous process. Where is the file?

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 thread to format data into a local file. Everything else on the Box is now running at a snail pace and where is the file?

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

This may also be caused by excessive create/destroy overhead. Creating a new Java thread usually means creating an operating system thread as well. This is no small task.

How Tymeac handles this.

So, you started a thread to format data into a local file. Oops, you now decide you want to cancel that thread.

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

How Tymeac handles this.

So, you started a thread to format data into a local file What you really need is to format multiple data sources and to put the results into multiple files.

Either you are going to have one very large Class doing multiple functions or multiple threads 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 thread to format data into a local file. 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 threads and requests without using temporary files?

How Tymeac handles this.

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

This can easily lead to a thread 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 threads 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 threads and the base server. It also requires GUI and non-GUI applications to present this picture to the user.

How Tymeac handles this.

So, you created a server with a nice pool of threads 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 threads 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 threads to handle requests. How can you debug this multi-threading application?

One thread at a time is easy. Even trapping a method in a thread is the mainstay of every IDE.

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 threads are running at any one time much less the current stage of processing of each individual thread.

How Tymeac handles this.

How Tymeac handles these problems.

Where is the file?

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. (See here)

Tymeac notifies system administrators when problems arise in the Server. You may tailor this to your own specifications. (See here)

Tymeac times the application processing so that excessive execution times can be trapped. (See here)

Tymeac handles abnormally ending applications by flagging the offender as no longer available. (See here)

Thread overload.

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. (See here for pooling and thread 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).

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 threads. (See here)

Persistence

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. (See here)

Stalls.

When threads 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. (See here)

Recursion

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. (See here)

Picture

Tymeac provides GUI clients for the following run time functionality:

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

Shut Down

Tymeac shuts down in multiple stages. (See here)

Hot fix.

Tymeac lets you change the Processing Application Class for any Queue at any time. (See here)

Debug

Debugging was a primary consideration during Tymeac design. (See here)

Tuning

Tuning starts at the design stage. Tymeac is the result of decades of experience. (See here)