radislavb / cluster-tasks-service Goto Github PK

cluster-tasks-service library is built to provide distribution of tasks across a clustered environment. Beside providing basic queue functionality in a clustered environment, cluster-tasks-service (henceforth CTS) employs several advanced distribution features.

Most significant feature, the one that CTS was originally written for, is an ability to control tasks processing in a channelled fashion, where only a single task from a specific channel will run at any given moment in the whole cluster.

• Configurer SPI - wiring library into consuming application
• CTS service - main library entry point
• Task processors - types and extensibility points
• Tasks - types, attributes, behaviors
• Monitoring - metrics and logs
• Examples
• Changelog

CTS is Spring based. Please follow the steps below to plug the library into your application lifecycle:

1. Setup the dependency in your pom.xml (as in example below) or other compatible build tool configuration (you may review the Changelog for an available versions):

   <dependency>
       <artifactId>cluster-tasks-service</artifactId>
       <groupId>com.microfocus</groupId>
       <version>${relevant.cts.version}</version>
   </dependency>
   

2. Make CTS's Spring beans available to your application. This could be done by either adding cluster-tasks-service-context.xml file to the list of your context path's in Java driven context initialization, or importing it from one of your own Spring XMLs, like in example below:

   <import resource="classpath:cluster-tasks-service-context.xml"/>
   

3. Implement ClusterTasksServiceConfigurerSPI interface and define your implementation as a Spring bean (singleton). Upon application start, CTS will wire this bean and take everything it needs from it (DataSource object, for example). See CTS configuration SPI overview for more details.

If these steps done right, CTS will kick in upon the application start and be available for submitting and processing tasks.

The world of CTS may roughly be separated into two:

• the CTS service itself is responsible for its environment setup, ongoing work and maintenance: collecting and registering processors, pulling and handing tasks over, statistics and monitoring, maintenance of finished/dead tasks etc. Service also provides few generic API for the consumer, for example API to enqueue tasks. Service import/bootstrapping is a one-time effort per application.
• a processors (aka Cluster Tasks Processor, aka CTP), implemented by library consumer and extending appropriate base abstract class, are an actual tasks processors with custom business logic, almost completely transparent to the framework. It is likely, that there will be many processors (CPTs) in your application, each handling specific use-case. Adding processors is an ongoing effort, aligned with the application evolution.