Differences

This shows you the differences between two versions of the page.

--- system:processes [2019/12/16 16:27] – emcodem
+++ system:processes [2024/01/28 10:26] (current) – benjamin
@@ Line 1: / Line 1: @@
 ====== Process overview ======
-{{:system:process_model_1.jpg?400 |}}
+{{gallery>:system:process_model_1.jpg?400x150&1200X1200&lightbox}}
 ==== General Information ====
@@ Line 21: / Line 21: @@
   * when rest_service is NOT installed, it fulfills the job of rest_service
-{{:system:process_with_transcode.png?900 |}}
+{{gallery>:system:process_with_transcode.png?900x150&1200X1200&lightbox}}
 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, e.g. def_runner.a3x and processors.a3x
@@ Line 30: / Line 30: @@
   * provide http API service
-{{:system:process_as_service.png?900 |}}
+{{gallery>:system:process_as_service.png?1200x150&1200X1200&lightbox}}
-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.
-{{:system:process_base.png?900 |}}
+{{gallery>:system:process_base.png?1200x150&1200X1200&lightbox}}
 In this picture, we see that exe_manager started a sub-process that is also called exe_manager but when looking at the "command line", we see that one of the exe_manager sub-processes takes care about def_runner.a3x
@@ Line 64: / Line 64: @@
 Whenever exe_manager found a new job ticket that needs to be processed on the current host, it will actually execute the "processor" that is described by the job ticket using processors.a3x.
+==== 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>:system:jobs_priority.jpg?700x350&1200X1200&lightbox}}
 ==== Job Ticket Management ====
-{{:system:processes_tickets.png?400|}}
+{{gallery>:system:processes_tickets.png?700x350&800X800&lightbox}}
 This picture shows how the different processes work with Job Tickets.
@@ Line 75: / Line 88: @@
   - 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
+==== The Status directory ====
+TOOD: processors.a3x checks for status pause or abort of a job split, exe_manager for ".start~%workflow_id%" to see if def_runner needs to be started
+---------------------------------------
+<html>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</html>[[system:processes|Back to top]]