Processing Pattern

The Processing Pattern

This is an example implementation of a Processing pattern, a generalized approach for submitting and asynchronously processing (ie: executing) "work" in a system.

The Processing Pattern advocates that;

1. ProcessingSessions are used to submit "work" (typically regular objects) for asynchronous processing.
2. A Submission Outcome must be returned after each submission to track the progress of said Submission.
3. A Processing Pattern client will only have to concern itself with the above two concepts.
4. A Processing Session can submit work and abandon it and later (or from a different session) reconnect to the submitted work.
5. Dispatchers are responsible for routing Submissions for processing.
6. A TaskDispatcher will dispatch special "work" which implements the Task interface.
7. A Task that implements ResumableTask interface can checkpoint state (checkpoint as in saving intermediate state which can be retrieved when resuming), yield execution and resume.
8. A TaskProcessor will process Tasks
9. A TaskDispatchPolicy will determine how Tasks are assigned to TaskProcessors.

This implementation of the Processing Pattern additionally advocates that;

1. Many Dispatchers may be configure to enable specific processing of different types of Submission.
2. Dispatchers are consulted in configuration order for each Submission to determine suitability for routing. (This is called "dispatch chaining").
3. Out of the box, three Dispatcher implementations are provided, one to Log the submissions, one to execute Java Runnables or Java Callables, and one (the DefaultTaskDispatcher) that dispatches Tasks to TaskProcessor implementations.
4. The available TaskProcessors are configured in the cache-config file
5. TaskProcessors can be of two different types, the GRID type instantiates automatically on each grid node. The SINGLE type is instantiated only on the node where it is configured.
6. Tasks are mapped to TaskProcessors using TaskDispatchPolicies
7. TaskDispatchPolicies include Round Robin, Random and Attribute Matching, the latter enabling an attribute supplied with a Submission to match against an attribute supplied with a TaskProcessorDefinition

Rationale

This implementation of the Processing Pattern provides a simple and powerful extensible framework for the processing of "work" across a Coherence Cluster. Work can be submitted without needing to know the internals of Coherence or building custom configurations. Unlike the traditional hub-and-spoke / master-worker / broker-agent, the Processing Pattern implementation avoids the classic "single-point-of-failure", "single-point-of-dispatch", "single-point-of-contention" problems as the core state management and distribution is managed by the Data Grid.

Additionally, it provides runtime support to ResumableTasks to enable checkpointing of long running work and a suspend/resume model enabling long running tasks.

Further it supports execution of work based on a run anywhere in the grid paradigm, as well as a more controlled execution model where work is run on specific nodes, either running as grid nodes or over Coherence*Extend.

What's New

Changes made as a part of version 1.3.4

• Fixed issue with rolling restart not working
• Fixed issue with leases being reregistered on failover
• Fixed issue where recycled member ids prevented restart of node

Changes made as a part of version 1.3.3:

• Fixed issue with acquireSubmission of a submission in final state.
• Fixed issue with NPE of extend based TaskProcessor (Single)
• Upgraded to use coherence-common-1.7.3

Changes made as a part of version 1.3.2:

• Upgraded to use coherence-common-1.7.2

Changes made as a part of version 1.3.1:

• Fixed issues related to multiple execution of one job when cluster growing/shrinking
• Fixed issue with flooding of Coherence event queue with many short lived tasks
• TaskProcessor timeout raised to 2 min 5 seconds to allow for default TCP timeout
• Upgraded to use coherence-common-1.7.1

The following changes have been made since the Processing Pattern 1.3.0 release.

• Resolved issues relating to multiple execution of one job when cluster growing/shrinking
• Resolved issues with flooding of Coherence event queue with many short lived tasks
• Increased TaskProcessor timeout raised to 2 min 5 seconds to allow for default TCP timeouts
• Upgraded to use coherence-common-1.7.1

The following changes have been made since the Processing Pattern 1.2.0 release.

• Introduced the ability to provide an Identifier for Submissions
• Introduced ability to reconnect to abandoned Submission
• Introduced ability to explicitly control lifecycle of the Submission and the result
• Introduced ability to retrieve a list of all active Submissions
• Upgraded to use Coherence Common 1.7

Basic design

Dispatchers and Submissions

1. In order to process work, one or more Dispatchers need to be registered.
2. When a dispatcher is registered, each Submission will be handed to each Dispatcher in registration order until
   one dispatcher accepts the Submission.
3. When a dispatcher has accepted the Submission a SubmissionOutcome is returned to the client.
4. When the dispatcher, (or in the case of Task dispatching, the TaskProcessor), has processed the Submission the SubmissionOutcome is signaled and the result is available to the client.

The following diagram illustrates the main structure of the design of the Processing Pattern.

Task dispatching and execution of ResumableTasks

1. ResumableTasks are handled by a TaskDispatcher that hooks in to the Dispatcher chain handling Submissions with a ResumableTask as the payload.
2. A TaskProcessor executes the ResumableTask.
3. Tasks are mapped to TaskProcessors using a configured TaskDispatchPolicy. The default TaskDispatchPolicy matches attributes supplied as part of the SubmissionConfiguration against attributes associated with a TaskProcessor
4. When a ResumableTask executes, a TaskExecutionEnvironment is available to support checkpointing, progress reporting and determination of resumption.
5. A resumable task can return a special Yield object to suspend execution.

The following diagram illustrates the structure of the Task Execution.

The following diagram illustrates the states a ResumableTask can be in.

Configuration of the Processing Pattern

Please go to this page Configuration for the Processing Pattern for an overview of how to configure the Processing Pattern.

JMX Monitoring

Please go to this page JMX Monitoring of the Processing Pattern for an overview of how to monitor the Processing Pattern using JMX.

In-depth example

For a more in-depth example of the Processing Pattern, please go to the Processing Pattern Examples.

Coherence 3.6 Support

Coherence 3.5 Support

Previous Releases

The following releases are provided for historical purposes only.
Processing Pattern 1.2.1, Processing Pattern 1.2.0

Screencasts

Coherence Screencasts
     Processing Pattern Overview
     Processing Pattern New Features Summer 2010

Detailed Documentation

How to use the ProcessingSession to manage Submissions and their lifecycle
Explains how to use a ProcessingSession to manage Submissions and cope with different use cases.
How to cancel a Submission
Explains how to cancel a Submission and what happens to executing Submissions.