automaton-simulation-de.scheduler
Scheduler The scheduler is creating the next scheduler snapshot, until the stopping criteria are met. It is executing scheduler middleware with each scheduler snapshot.
For each scheduler snapshot created, the scheduleris 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-eventwhich is the current event to executestatewhich is the state value before the event executionnew-future-eventswhich 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.
This event-return contains the stop reason, that could be:
-
::no-future-eventswhen no future events exists -
::causality-brokenwhen the date of the event is in the past -
::execution-not-foundwhen the type is unknown -
::failed-event-executionwhen the execution of the event if raising an exception -
::nil-handlerwhen the handler is not given -
::max-iteration-numberthe maximum iteartion number is reached -
Causality
Causality is a property of the simulation model stating that a future event cannot change what has been done in the past already, so all changes in the state should not contradict any past event. For instance, anticipating an event would lead to causality violation.
Scheduler The scheduler is creating the next scheduler snapshot, until the stopping criteria are met. It is executing scheduler middleware with each scheduler snapshot. For each scheduler snapshot created, the scheduleris 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. This `event-return` contains the stop reason, that could be: * `::no-future-events` when no future events exists * `::causality-broken` when the date of the event is in the past * `::execution-not-found` when the type is unknown * `::failed-event-execution` when the execution of the event if raising an exception * `::nil-handler` when the handler is not given * `::max-iteration-number` the maximum iteartion number is reached * [See entity](docs/archi/scheduler_entity.png) * [See aggregate](docs/archi/scheduler_aggregate.png) * [See state diagram](docs/archi/scheduler_state.png) ### Causality Causality is a property of the simulation model stating that a future event cannot change what has been done in the past already, so all changes in the state should not contradict any past event. For instance, anticipating an event would lead to causality violation.
handlerclj/s
(handler request)Handler is executing a request and returning a response.
An handler could be wrapped with middlewares. Params:
request
Handler is executing a request and returning a response. An handler could be wrapped with middlewares. Params: * `request`
iterateclj/s
(iterate registry sorting handler snapshot)Iterates on the scheduler, it executes the handler based on data in the snapshot and creates the next one.
The event that is executed thanks to the code found for that event in the registry
A scheduler iteration should not access past or future events to have some information on the state of the simulation
Params:
registryregistry mapping event type to event executionsortingsnapshotsnapshot that will be used to iterate
Returns the response, the next snapshot, with state, future and past data updated according to event execution.
Iterates on the scheduler, it executes the handler based on data in the snapshot and creates the next one. The event that is executed thanks to the code found for that event in the `registry` A scheduler iteration should not access past or future events to have some information on the state of the simulation Params: * `registry` registry mapping event type to event execution * `sorting` * `snapshot` snapshot that will be used to iterate Returns the response, the next snapshot, with state, future and past data updated according to event execution.
schedulerclj/s
(scheduler registry middlewares ordering initial-snapshot max-iteration)The scheduler is creating the next scheduler-snapshot, until the stopping criteria are met. It is executing scheduler middleware with each scheduler snapshot.
For each scheduler-snapshot created, the scheduler is sorting the future events based on the event ordering defined in the event-registry. The first element in ordering is sorted first, in case of tie, the second order is used, and so on.
The first event of that order is the current event, this event is executed (see event-execution). The resulting new values of state, past events, future events are used to create the new scheduler-snapshot.
Stopping criteria is checked by looking for :stop key in scheduler-iteration state being true.
Params:
registryregistry mapping event type to event execution.middlewareslist of middlewares, executed from left to right forrequestand from right to left forresponse.orderingsort two events.initial-snapshotthe snaphost to start with.max-iterationmaximum iteration number to limit endless simulation.
Returns last snapshot
The scheduler is creating the next `scheduler-snapshot`, until the `stopping criteria` are met. It is executing scheduler middleware with each scheduler snapshot. For each `scheduler-snapshot` created, the scheduler is sorting the future events based on the event `ordering` defined in the `event-registry`. The first element in ordering is sorted first, in case of tie, the second order is used, and so on. The first `event` of that order is the current event, this event is executed (see `event-execution`). The resulting new values of state, past events, future events are used to create the new `scheduler-snapshot`. Stopping criteria is checked by looking for `:stop` key in scheduler-iteration state being `true`. Params: * `registry` registry mapping event type to event execution. * `middlewares` list of middlewares, executed from left to right for `request` and from right to left for `response`. * `ordering` sort two events. * `initial-snapshot` the snaphost to start with. * `max-iteration` maximum iteration number to limit endless simulation. Returns last `snapshot`
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close