Every Kompics component has a lifecycle of 5 specific states it can be in, which controls what kind of events it will execute and when it will be deallocated (and thus allowed to be garbage collected eventually).
These 5 states are
and are defined in
The transitions between these states happen via the following events on the
ControlPort or a fault (an exception being thrown) in one of the component’s handlers, or the method
ComponentCore.markSubtreeAs(State) (during fault handling):
Every component C begins in
PASSIVE after creation. In this mode no events are handled except lifecycle events, all other events are simply queued up on their respective ports.
The handling of a
Start event moves C into the
STARTING state, where it still won’t handle anything but lifecycle events. C automatically forwards the
Start event to all its children und waits for them to reply with
Started. Once all children have done so, C moves into the
ACTIVE state and replies to its parent component with
ACTIVE state is the normal operating state of a component, where it handles all events as described previously during the Kompics Tutorial.
The handling of a
Kill events changes C’s state to
STOPPING. As before, it forwards the respective event to all its children and waits for
Killed messages from all of them before proceeding. However, a
STOPPING component handles events on other ports normally. Once all replies are received the component moves into the
PASSIVE state and sends
Killed to its parent component. If the original event was
Stop it simply remains there until restarted as above. If the original event was
Kill the component will run
ComponentCore.destroyTree(ComponentCore) to sever all its connections and set its whole subtree to
DESTROYED. From here it can not be restarted and parent components should take care to clean up any remaining references to the component, so that it will be garbage collected eventually.
It is possible to inspect a component’s current state via
Component.state(), for example to judge during handler execution if a component is already
STOPPING. However, it should be noted that calls to this method are not synchronised in any way, and may return inconsistent results due to concurrent modification. They should thus be regarded as a mere indicatior of state, not a guarantee.
If a fault occurs during the execution of a handle in component C, its whole subtree will be set to
FAULTY immediately (not interrupting running handlers in its children, but preventing handling of further events). Consequently the parent component P’s
ComponentDefinition.handleFault(Fault) method will be consulted to resolve the issue. If not overriden, the fault is simply escalated from level to level, until eventually the root fault handler causes resolution (for example, via either system shutdown or a complete restart of the hierarchy). Other choices of
RESOLVED, which causes no further within the Kompics systems, the assumption being that the user somehow resolved the issue
IGNORE, which causes resumption of C and its subtree, by setting it to
PASSIVEand triggering a
DESTROY, causing the whole subtree of C to be scrapped immediately.