The scheduler is working with a model describing the problem to solve.
For each scheduler snapshot created, the scheduler is sorting the future-events based on the event ordering defined in the event-registry. The first event of that order is executed (see event execution). The resulting new values of state, past events, future events are used to create the new scheduler snapshot.
An event has three parameters (event-execution current-event state new-future-events):
current-event which is the current event to executestate which is the state value before the event executionnew-future-events which is the list of future events without the current eventThe returned value is a event-return, which future events have no needs to be sorted, they will be by the scheduler.
The `scheduler` is working with a `model` describing the problem to solve. For each scheduler snapshot created, the scheduler is sorting the `future-events` based on the event ordering defined in the event-registry. The first event of that order is executed (see event execution). The resulting new values of state, past events, future events are used to create the new scheduler snapshot. An event has three parameters `(event-execution current-event state new-future-events)`: * `current-event` which is the current event to execute * `state` which is the state value before the event execution * `new-future-events` which is the list of future events without the current event The returned value is a `event-return`, which future events have no needs to be sorted, they will be by the scheduler.   
(handler {:automaton-simulation-de.simulation-engine/keys
[stopping-causes snapshot event-execution sorting current-event]
:as _request})The handler execution is based on request data and is returning a response, it could be enriched with middlewares.
The response is initiated with the stopping-causes of the request, and the snapshot. If succesful, it is updated with state and future-events of the event-execution.
It may happen that errors occur and handler creates stopping-cause as:
sim-de-execution-not-found if an event-execution is not found, that event is moved to past-events and the stopping-cause added.sim-failed-event-execution if an exception is raised during event-execution, the stopping-cause is added.The handler execution is based on `request` data and is returning a `response`, it could be enriched with `middlewares`. The `response` is initiated with the `stopping-causes` of the `request`, and the `snapshot`. If succesful, it is updated with `state` and `future-events` of the `event-execution`. It may happen that errors occur and `handler` creates `stopping-cause` as: * `sim-de-execution-not-found` if an `event-execution` is not found, that event is moved to `past-events` and the `stopping-cause` added. * `sim-failed-event-execution` if an exception is raised during `event-execution`, the `stopping-cause` is added.
(invalid-inputs model
scheduler-middlewares
scheduler-stopping-criterias
snapshot)Returns a map describing why it is invalid or nil if it is valid.
Returns a map describing why it is invalid or `nil` if it is valid.
(scheduler model scheduler-middlewares scheduler-stopping-criterias snapshot)The scheduler executes the model until a stopping-cause is met.
Note that users can enrich the execution of it by:
model with augmented registries.Note that particular attention has been paid to leverage model's preparation, e.g. stopping-criteria and middlewares aren't translated again, just their scheduler version is.
Returns a response with the last snapshot and the stopping-causes.
The scheduler executes the `model` until a `stopping-cause` is met. Note that users can enrich the execution of it by: * enriching the `model` with augmented registries. * supplementary middlewares and stopping criteria that don't affect the model Note that particular attention has been paid to leverage model's preparation, e.g. stopping-criteria and middlewares aren't translated again, just their `scheduler` version is. Returns a `response` with the last snapshot and the `stopping-causes`.
(scheduler-loop event-registry
sorting
ahandler
{:automaton-simulation-de.simulation-engine/keys [future-events]
:as snapshot}
stopping-criterias)scheduler-loop is one loop iteration of the scheduler.
It is picking the first event of the future-events is the current-event, used to get the event-execution.
It starts with the build of a request, call the handler wrapped in middlewares and add current-event to the potential stopping-causes
Some error may create some stopping-causes, they are not stopping execution here, to give a chance to middlewares to add some other stopping-causes:
no-future-events which is happening when no event is found in the future-events to be executed.`scheduler-loop` is one loop iteration of the scheduler. It is picking the first `event` of the `future-events` is the `current-event`, used to get the `event-execution`. It starts with the build of a `request`, call the `handler` wrapped in `middlewares` and add `current-event` to the potential `stopping-causes` Some error may create some `stopping-causes`, they are not stopping execution here, to give a chance to middlewares to add some other `stopping-causes`: * `no-future-events` which is happening when no event is found in the `future-events` to be executed.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |