It's assumed that readers understand [[Architecture]], [[Terminology]], [[Communication]] and [[Assignments Overview]]. This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution.
It's assumed that readers understand [[Architecture]], [[Terminology]], [[Communication]] and [[Assignments Overview]]. This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution. Only hot path is considered in following description.
## Web Application
## Web Application
@ -66,13 +66,13 @@ Worker gets request from broker to evaluate particular submission. Next step is
Broker gets done message from worker and basically only mark submission as done in its internal structures. No messages are send to web application, because of lazy evaluation on frontend side. More detailed description follows:
Broker gets done message from worker and basically only mark submission as done in its internal structures. No messages are send to web application, because of lazy evaluation on frontend side. More detailed description follows:
- T
- broker gets "done" message from worker after successfull execution of job
- O
- appropriate `worker` structure is found based on its identification
- D
- some checks of invariants (current job identification, right amount of arguments) are executed right now
- O
- deletion of current execution request in `worker` structure follows and appropriate worker is now considered free
- .
- if worker execution queue is not empty than next waiting request is taken and given as current one
- .
- after that only missing thing is to send that request to worker and loop back to worker execution
- .
- if worker queue is empty then appropriate worker remains free and waiting for another execution request