CoopSoft Logo
Cooperative Software Systems


Home Products Company Contacts News Licensing


















     Push Engine

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.

Tymeac is

  1. 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.
  2. An efficient multitasking service that allows many resource-intensive applications to coexist in a single microservice.
  3. 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.
  4. A flexible push engine that supports non-blocking backpressure. You can cancel (with a reason), pause/resume and alter any application at anytime.
  5. A resilient push engine that supports multiple timeout scenarios to handle unresponsive applications.
  6. A scalable push engine since Tasks are separate from the threads.
  7. 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.

  8. A tunable push engine. Every Queue and Thread has a management structure to facilitate tuning.
  9. 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 detail.


Tymeac provides a

  microservice arictecture with

  high-quality thread management in a

  [separate JVM | internally] with a

  minimal footprint that is

  easy to use.

Tymeac supports both communal and distinct processing.

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" playground.

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 asynchronous threads.

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 works:

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 much more.

If you need a secure, reliable, manageable and fault tolerant Asynchronous Stream Builder
        for any purpose and do not wish to start at the beginning designing and testing one yourself,
        then you need Tymeac

Tymeac is available with both an open-source license (Apache)
and a paid commercial license.

Download the latest Edition




Tymeac is a trademark of Cooperative Software Systems.
Java, 100% Pure Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates


1998 - 2017 Cooperative Software Systems  All rights reserved.