Version 1.4.0 #52
Merged
Version 1.4.0 #52
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closes #26 No need to change the factories and no need for a `PromiseHandleFactory`
There are a few design decisions to be made
See #34 Need to fix and extend testing Need to see if it fits with Kafka and Aurora stuff
# Conflicts: # src/com/workflowfm/pew/PiEvents.scala
This makes for a cleaner, more flexible implementation, allowing multiple simulations across multiple `Coordinator`s. The downside is that simulations can be run asynchronously, making it hard to disambiguate which results came from which `Coordinator`. We leave that problem to the user for now.
Documentation of real-time and simulation metrics for v1.4.0
No longer needs the internal counter as well. Also fixed `MetricsHandler` to not need a name.
Using a separate AkkaExecutor for each simulation is inevitable at this point... The problem is just too complex otherwise. 1) Atomic processes run in their own actor, but they don't have access to it in advance, so they can't receive directly. We use the ask pattern for that. 2) They need to communicate with the SimulationActor to queue tasks, so they need to know its ActorRef in advance. 3) The SimulationActor needs to know the Executor in advance so that it can start the simulation when instructed by the Coordinator. 4) The Executor needs to know the available processes in advance. Hence the cycle. I tried to make the executor a variable in SimulationActor, but now stuck at (4). The PiProcessStore in AkkaExecutor is mutable, but that is too much mutability for my taste. I think having the SimulationActor generate its own AkkaExecutor will do at least for now.
Realised that ready() gets called before the processes have a chance to register their tasks.
Resolved multiple race conditions. Everything looks fine now. We only need to deal with processes that register multiple or no tasks. QueueMachine in Aurora for example. We need to take care of removing them from the taskWaiting list. For multiple tasks, we might want to add them once for each task they register and avoid the additional ready call. For no tasks, we need to think about managing multiple instances with the same name. Perhaps we can use metadata to register our own unique ID for all processes?
If the process takes too long to declare itself resumed, we may proceed the coordinator before it resumes.
Also tightens synchronisation when waiting/resuming
Simulation rework
Also allows swapping of the process map in a `PiInstance`/`PiState`. Closes #44
Things like `SimulationExecutor`, `PiInstance.isSimulationReady` etc are no longer needed.
Affects `AkkaExecutor`, though it already had a timeout parameter
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Release of v1.4.0.
This includes:
PiInstanceSimulation should be able to start from a custom, intermediate PiInstance #44