To reduce the impact of setup time on the overall duration of a distributed task, it is not necessary to have all of the subtasks loaded before starting the distributed task. Options would include simply aborting the distributed task, fixing the input data and adding it to the end of the subtask list, or some other application-defined behavior. The controller will call the NotifySubTaskException method with the subTaskId and the exception that was thrown by the worker allowing the distributed task to determine the next course of action based on that failure. If an exception occurs in a subtask, the worker and controller leverage the built-in fault handling support of MassTransit to notify the distributed task that an exception has occurred. This will register the SubTaskWorker for the worker as a message handler for the messages that are used on the transport to transfer the input and output data between the controller and the subtask workers. The worker can then be added to the container for servers that will be processing the subtasks using: Public void ExecuteTask(GenerateFileHash input, Action output) For example, a worker that accepts a GenerateFileHash object and outputs a FileHashGenerated object would be setup as shown: This worker handles the coordination with the DistributedTaskController, along with the delegation of the messages to the actual subtask worker.
![masstransit handler masstransit handler](https://www.minnpost.com/wp-content/uploads/2021/07/GasPumpThumb.png)
To make it easy to create workers to handle subtasks, a default worker implementation is available. TTask is the class that implements IDistributedTask, TInput is the subtask input type, and TOutput is the subtask output type. The controller performs any initial identification of workers that are available to process the subtasks, along with the coordination to ensure that workers are not overloaded. Start() to being processing the distributed task. This class is built from the class that implements IDistributedTask, along with the input and output types. To insulate the application from the details of coordinating the subtasks, a generic DistributedTaskController is used. These input types are used to determine which workers are used to process the subtasks. A subtask has specific input and output types, each of which are defined by a class (POCO style).
![masstransit handler masstransit handler](https://i0.wp.com/portfolio.panynj.gov/wp-content/uploads/2018/08/papd-officer-tim-brennan-and-k9-partner-tonga-training-at-ewr-airport.jpg)
There is no attempt to execute the subtasks within a distributed task in order. Each subtask should be completely standalone and not depend upon the completion of any other subtask within the distributedtask. Void NotifySubTaskException(int subTaskId, Exception ex) Ī subtask is an individual unit of work within a distributed task. Void DeliverSubTaskOutput(int subTaskId, TOutput output) The input and output types for the subtasks must also be defined by the distributed task class. To create a distributed task, create a class that implements IDistributedTask. The following sections define the language used in the distributed task classes.Ī distributed task contains one or more subtasks that need to be processed concurrently across multiple systems. The result is a new MassTransit.Grid namespace that includes support for building distributed task processing into an application.
![masstransit handler masstransit handler](https://cdn.modernghana.com/content/600/360/stc2.jpg)
![masstransit handler masstransit handler](https://i2.wp.com/portfolio.panynj.gov/wp-content/uploads/2018/08/papd-officer-tim-brennan-and-his-k9-partner-tonga.jpg)
The article gave me some ideas and I decided to see what it would take to build a distributed processing system on top of MassTransit. I was reading through the Xgrid documentation for OS X yesterday after reading an article on Integrating Xgrid Into Cocoa Applications. Distributed Processing with MassTransit.Grid 23 August, 2008.