When you have multiple Push requirements for each Publisher.
When you have multiple Publishers living in one JVM.
Then the key to success is separating each individual push operation
(Task) from its Publisher. Each Task can execute in an efficient
multitasking service; Tymeac for Reactive Stream generation/distribution.
- An efficient push engine allowing (Reactive
Stream) Publishers to generate
asynchronous streams for routing to Subscribers. Tymeac is not
a "Publisher" itself. However, Since the Publisher exports the
subscription work (filter, etc.) to Tasks the Publisher can run as a
Tymeac Task itself and does not need to tie up a thread.
- An efficient multitasking service that allows many
resource-intensive applications to coexist in a single microservice.
- A 100% pure Java push engine. Tymeac does not rely on outside
packages to multitask. No preprocessors, no runtimes, no limits on
hardware. If your application runs on Java SE, it runs without any
modification or additional downloads with Tymeac.
- A flexible push engine that supports non-blocking backpressure.
You can cancel (with a reason), pause/resume and alter any application at
- A resilient push engine that supports multiple timeout scenarios to
handle unresponsive applications.
- A scalable push engine since Tasks are separate from the threads.
- A full featured push engine. Tymeac comes with nineteen JavaFX GUI's and client
program access so you can monitor/alter the executing request and server. And five
more JavaFX GUI's for backend setup.
- A tunable push engine. Every Queue and Thread has a management structure to
- A well documented push engine. While JavaDoc is nice for API's, a professional
microservice requires professional documentation.
|Read an article by one of our
developers that expounds this simple definition with images and more
microservice arictecture with
thread management in a
[separate JVM | internally] with a
easy to use.
Tymeac supports both communal and
How communal processing works:
Communal means community. In a community, players play nice with
each other. Those that don't play nice ruin it for everyone. If a
player is not going to play nice, then that player belongs in the "distinct"
The Task is the heart of processing. A Task contains the
variables/methods Tymeac needs to multitask your requests. All your
user classes must extend this class. A Task can be
- actively computing a stream or
- timed-waiting for a resource (database/file access, internet
access, or other service access) The timeout is a way to handle
non-responsive accesses, or
- waiting for a send to complete (onNext, etc.)
While that Task is waiting for something, Tymeac can
put the Task in suspension freeing the thread for other work. This
is simple task-management that most operating systems use to
schedule work on processors. Tymeac cannot do a context-switch.
Tymeac relies on the Task cooperating by the Task setting pending
action (need a send, need a resource) and returning from the
method call rather than blocking.
Tymeac is a superb implementation of a very simple concept:
Put requests in queues for processing by
Tymeac uses three queues: Active, Sending and
Suspended. Each Queue has a dedicated thread pool.
The Active Queue is for threads to fetch
Tasks [low CPU usage Publishers and subscriber-objects] so the
Tasks may compute that which they do. When a Task
needs a resource the Task starts the asynchronous access,
sets an estimated delay time it believes the
access may take (the pending action here is a delay to
await completion) and returns unless it also needs to send data.
When a Task needs to send a stream (onNext, etc.) the Task sets a
send-pending (the pending action) and returns. If there is
a send-pending, Tymeac moves
the Task to the Sending Queue. If there is no send-pending
but there is a delay pending
Tymeac moves the Task to the Suspended Queue.
The Sending Queue is for threads to fetch
Tasks and use the Observer<T> to send the asynchronous stream (onNext/Error/Completed.)
Once the send is complete Tymeac moves the Task back to the
Active Queue, or, if there is still a delay outstanding,
Tymeac moves the Task to the Suspended Queue.
The Suspended Queue is for waiting for an
event to complete (delay to elapse or one of those asynchronous
accesses to complete.) Once the event finishes, Tymeac moves the
Task back to the Active Queue.
In this way Tasks cooperate with other Tasks by not
tying up a thread with blocking calls. Compute what you need.
Relinquish the thread when you need to wait. The system can support
hundreds/thousands of active requests with just a few threads.
How distinct processing
Tymeac uses one queue: Distinct. The Queue has a
dedicated thread pool.
The Distinct Queue is for [high CPU usage
Publisher] Tasks to do everything which they do; access resources,
wait for those resources. Tasks cannot send using the Sending Queue.
Tasks certainly may execute any communication they need, just not
using the Sending Queue, that is for Communal Tasks only. Once here,
they stay here until the request completes. The difference between a
general thread pool and Distinct processing is that Tymeac manages
persistence, messaging, queuing, threads, stall detection and
recovery, recursion, logging, statistics, the user interface and
If you need a secure,
reliable, manageable and fault tolerant Asynchronous Stream
for any purpose and do
not wish to start at the
beginning designing and testing one yourself,
then you need Tymeac™
is available with both an open-source license (Apache)
and a paid commercial license.
Help support this project and the related Java
Parallel projects with a donation.
Tymeac is a trademark of Cooperative Software
Java, 100% Pure Java, and all Java-based trademarks and
logos are trademarks or registered trademarks of Oracle and/or its affiliates