Normally you think of a Queue as a list of pending requests with methods like
add() and remove(). Priority Queues, Blocking Queues etc are supported in the
java.util package.
Tymeac Queues are all that and more. Tymeac Queues are actually a Queue
framework. That is, the list and everything else needed to sustain it. Tymeac Queues
support :
Priority
A priority queue relies on some internal field for sorting. Every request
that goes into the queue needs to compare to other requests already in the queue
to see where it should go. Duplicate priorities generally resolve arbitrarily.
That's slow, very limited and subject to FIFO errors.
Tymeac does not use the standard priority queue.
Tymeac uses separate Wait Lists. Each Wait List (ConcurrentLinkedQueue) is
the priority. If supporting ten priorities, then we have ten Wait Lists.
Priority 1, goes into Wait List 1, etc. By separating the work in this way we
can do amazing things. And you can support
your own priority structure in the caller. (E.G. incoming comparators aaa - azz
resolve to priority 1, etc.)
Both add() and remove() are fast. Inquiry for each priority is fast. Tymeac
handles the FIFO problem.
The Wait Lists are bounded. Having an unbounded entity means that we run out
of memory before we know there is a problem. With Tymeac, a 'no Wait List
available' condition is a recoverable exception. The easiest solution is
to dynamically add more elements to each Wait List.
Thresholds
By having Wait Lists, we can easily support thresholds for controlling the
number of threads executing at any given time.
Threads consume resources. They eat memory voraciously. Unless you have many, many free
CPU's just waiting for work, threads compete for CPU cycles. They compete with
each other for locks. The list goes on and on.
When a thread can process a request in a short time period, then using more
than the minimum number of threads for a lightly loaded Queue is a waste of
resources and may even slow down overall processing.
Tymeac supports thresholds for
keeping the number of competing threads under control. The Tuning Document discusses this in detail and
gives many examples.
Thread Pools
Traditional thread pools are like pools of sharks. You certainly wouldn't
want to venture in there.
Managed threads are the answer.
User Class
In Tymeac we call this the Processing Application Class. Developing Your Applications discusses this in
detail.
A Processing Application Class is the code you write to process the specifics
of the application. A Tymeac managed thread uses reflection to invoke the main()
method of your class.
This is the decoupling that is so important in good application design. You
supply the application logic in a Processing Application Class. Tymeac handles
the threading logic.
Error Recovery
This is the part that separates the men from the boys.
Tymeac separates your request (Tymeac Function) into its components (Tymeac Queue) and
schedules each Tymeac Queue. If scheduling fails on
any Tymeac Queue, then Tymeac tries to back out the already scheduled Tymeac
Queues.
- Back out tries to remove the request from a Tymeac Queue Wait List if
the request hasn't started executing.
- If the request is already executing, Tymeac informs the managed thread
to ignore any returned objects from the application.
- If an asynchronous request, Tymeac informs the managed thread not to
start the Output Agent processing.
- The calling Client is informed of the
specific reason for the failure.
Tymeac supports the timed request (syncRequest()). If the time expires before the request
completes, Tymeac tries to back out the request, as above.
Tymeac supports the asynchronous or autonomous request (asyncRequest()). You call the Tymeac
Server for a request and receive a "was scheduled" message in response. The
actual processing takes place asynchronously.
What if something goes wrong in an asynchronous request? How would anyone
know? Unlike the synchronous request where the Client gets the return data from
the processing, the asynchronous request is on its own. When things go wrong in
asynchronous requests, Tymeac puts the request into a
Stall Array. An administrator may then deal intelligently with the request.
When exception occur, Tymeac doesn't just let the system print an ugly
message and die. Tymeac catches exceptions, prints and logs meaning full messages with full documentation,
notifies administrators of the problem and tries recovery.
What if something goes wrong on the Client side and that Client needs to
cancel an in-progress request? No problem. Tymeac supports
cancelling requests.
Tymeac uses a Monitor (daemon) that scans the
environment periodically looking for problems, notifying administrators when
problems (real or potential) exist and recovering resources.
Control
Tymeac provides seventeen GUI's (and programming access) to the server
environment so users may view and alter parameters dynamically.
Need to track the request during it's life cycle? What stage of processing is
that asynchronous request you sent? No problem.
Are any asynchronous requests stalled and can you view, reschedule or purge a
request? No problem.
What is the load on each thread in the Queue? No problem.
Need to alter thread parameters? No Problem
What is the load on each Wait List in the Queue? No problem.
Need more Wait List elements? No problem.
Need to alter the Processing Application Class? No problem.
Tymeac is a professional product. Professionals know how important it is to
provide total control over the Queue.
Tymeac manages Queues.