Page History

...

• CL-runtime sends CONTROL_LOOP_UPDATEmessage to all participants with startPhase = 0
• participant receives the CONTROL_LOOP_UPDATEmessage and runs to PASSIVE state (only the CL element is define as startPhase = 0)
• CL-runtime receives CONTROL_LOOP_UPDATE_ACT messages from participants and set the state (from the CL element of the message) to PASSIVE
• CL-runtime calculates that all CL elements with startPhase = 0 are set to proper state and sends CONTROL_LOOP_UPDATE message to all participants with startPhase = 1
• participant receives the CONTROL_LOOP_UPDATEmessage and runs to PASSIVE state (only the CL element is define as startPhase = 1)
• CL-runtime calculates that all CL elements are set to proper state and set CL to PASSIVE

In that scenario the message CONTROL_LOOP_UPDATE has been sent two times.

SupervisionAspect

• ThreadPoolExecutor: in this context is configured to execute task in ordered manner, one by one.
• Scheduling: is used to schedule retry task.
• MessageIntercept: is used to intercept messages from participants

HandleCounter

• remove(id) -> used to remove from monitoring
• clear(id)  -> used to clear/start monitoring

Design of a PARTICIPANT_REGISTER message

...

Design of a PARTICIPANT_UPDATE_ACK message

Participants sends PARTICIPANT_UPDATE_ACK messages in response to a PARTICIPANT_UPDATE message.

• the message is collected by ParticipantUpdateAckListener
• from MessageIntercept the event is intercepted and it add a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner
• in SupervisionScanner remove the monitoring for participantUpdate
• update the status of the participant to db    

...

Design of a CONTROLLOOP_UPDATE_ACK message

Participants sends CONTROLLOOP_UPDATE_ACK messages in response to a CONTROLLOOP_UPDATE  message. It will send a CONTROLLOOP_UPDATE_ACK for each CL-elements moved to the state as indicated by the CONTROLLOOP_UPDATE.

• the message is collected by ControlLoopUpdateAckListener
• from the control loop into the message check the status of all control loop element and check if the control loop is primed
• update the CL into the db if it is changed
• from MessageIntercept the event is intercepted and it add a task to handle a monitoring execution in SupervisionScanner

Design of a CONTROLLOOP_STATECHANGE_ACK message is similar to the design for CONTROLLOOP_UPDATE_ACK

Solution Design of retry, timeout, and reporting for all Participant message dialoguesDesign of monitoring execution in SupervisionScanner

...

• determination of the next startPhase in a CONTROLLOOP_UPDATE message. 
• upgrade CL state: in a scenario that CL state are in kind of transitional state (example UNINITIALISED2PASSIVE), if all CL-elements are moved properly to the specific state, the CL state will be upgrade to that.
• retry CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE messages. if there is a CL Element not in the proper state, will be retry a broadcast message.
• retry PARTICIPANT_UPDATE message to the participant in a scenario that CL-runtime do not receive PARTICIPANT_UPDATE_ACT from it.
• send PARTICIPANT_STATUS_REQ to the participant in a scenario that CL-runtime do not receive PARTICIPANT_STATUS from it, 

The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution

...