system:processes
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| system:processes [2019/12/16 15:16] – [Example Workflow Execution] emcodem | system:processes [2024/01/28 10:26] (current) – benjamin | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Process overview ====== | ====== Process overview ====== | ||
| - | {{: | + | {{gallery>: |
| ==== General Information ==== | ==== General Information ==== | ||
| Line 12: | Line 12: | ||
| * Farm Mode | * Farm Mode | ||
| - | Note that there is no difference between running on a standalone host or in a farm. The processes are the same on each and every member of the farm. | + | Note that there is no difference between running on a standalone host or in a farm. The processes are the same on each and every member of the farm. All nodes look for new Job tickets in the same folders and compete against each other getting a job assigned (depending on CPU settings, "farm host exceptions" |
| Line 21: | Line 21: | ||
| * when rest_service is NOT installed, it fulfills the job of rest_service | * when rest_service is NOT installed, it fulfills the job of rest_service | ||
| - | {{: | + | {{gallery>: |
| In this picture, we see ffastrans.exe on a standalone host, not installed as service. ffastrans.exe took care about starting exe_manager which again started different sub-processes, | In this picture, we see ffastrans.exe on a standalone host, not installed as service. ffastrans.exe took care about starting exe_manager which again started different sub-processes, | ||
| Line 30: | Line 30: | ||
| * provide http API service | * provide http API service | ||
| - | {{: | + | {{gallery>: |
| - | In this picutre, we see that rest_service.exe took care about starting exe_manager. | + | In this picture, we see that rest_service.exe took care about starting exe_manager. |
| Line 56: | Line 56: | ||
| def_runner.a3x is started by exe_manager in case there are any active workflows that need watching for new files. | def_runner.a3x is started by exe_manager in case there are any active workflows that need watching for new files. | ||
| - | {{: | + | {{gallery>: |
| In this picture, we see that exe_manager started a sub-process that is also called exe_manager but when looking at the " | In this picture, we see that exe_manager started a sub-process that is also called exe_manager but when looking at the " | ||
| Line 65: | Line 65: | ||
| - | ==== Example Workflow Execution | + | ==== Priority flow chart and example |
| - | {{: | + | Since the 1.1.0.0 FFAStrans release, all the jobs are processed regarding to their priority : |
| + | \\ FFAStrans Workflow properties\Priority -> 0(Very Low)-1(Low)-2(Normal)-3(High)-4(Very High) \\ | ||
| + | //**Each time a new higher priority branch (or job) is being put into queue, it will start before all lower priority queuedjobs *// | ||
| + | //**Once a branch/job has been started, the priority does not matter anymore *// | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | Example for 4 max active jobs on 1 host, 2 hosts with 2 max active jobs or 4 hosts with 1 max active job: | ||
| + | \\ | ||
| + | {{gallery>: | ||
| + | |||
| + | ==== Job Ticket Management ==== | ||
| + | |||
| + | {{gallery>: | ||
| This picture shows how the different processes work with Job Tickets. | This picture shows how the different processes work with Job Tickets. | ||
| - | - Various job starting methods create tickets in either pending or queued folder | + | - Various job starting methods create tickets |
| - Queued or pending tickets are being read by exe_manager | - Queued or pending tickets are being read by exe_manager | ||
| - exe_manager spawns a processors.a3x process for each ticket | - exe_manager spawns a processors.a3x process for each ticket | ||
| - processors.a3x reads ticket, decides if the current host and CPU allows to execute the ticket and in case it executes the processor from the current ticket | - processors.a3x reads ticket, decides if the current host and CPU allows to execute the ticket and in case it executes the processor from the current ticket | ||
| - when the processor finished, processors.a3x parses from the workflow which processors are next to be executed and places the corresponding tickets into queued folder, the process starts over at 3 | - when the processor finished, processors.a3x parses from the workflow which processors are next to be executed and places the corresponding tickets into queued folder, the process starts over at 3 | ||
| + | |||
| + | ==== The Status directory ==== | ||
| + | |||
| + | TOOD: processors.a3x checks for status pause or abort of a job split, exe_manager for " | ||
| + | |||
| + | --------------------------------------- | ||
| + | |||
| + | < | ||
system/processes.1576509391.txt.gz · Last modified: 2020/11/16 19:08 (external edit)