Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • When participant go OFF_LINE:
    • if there are compositions connected to that participant, ACM-runtime will find other ON_LINE participant with same supported element type;
    • if other ON_LINE participant is present it will change the connection with all compositions and instance;
    • after that, it will execute restart for all compositions and instances to the ON_LINE participant.
  • When receive a participant REGISTER:
    • it will check if there are compositions connected to a OFF_LINE participant with same supported element type;
    • if there are, it will change the connection with all compositions and instances to that new registered participant;
    • after that it will execute restart for all compositions and instances changed.
    • Refactor restarting scenario to apply the restarting only for compositions and instances in transition

Note: Participants create randomly participantId and Kafka consumerGroup. This solution has been tested and has the issue to create a new Kafka queue in restarting scenario. 
During restart scenario, a new consumerGroup is created, that cause some missing initial messages due the creation of new Kafka queue . The result is that to fail to receive messages from ACM to restore compositions and instances.

...


- name: SPRING_CONFIG_NAME
value: /path/to/${HOSTNAME}.yaml

For example considering the http participant replica, ${HOSTNAME} will be "policy-http-ppnt-0" and "policy-http-ppnt-1" and their
corresponding properties files with the names "http-ppnt-0.yaml" and "http-ppnt-1.yaml" is volume mounted.

Note: In a scenario of two participants in replicas (we are calling "policy-http-ppnt-0" and "policy-http-ppnt-1"), ACM-Runtime will assignee randomly any composition definition in prime time to specific participant based of supported element definition type. So we could have a scenario where a composition definition "composition 1.0.0" is assigned to policy-http-ppnt-0 and the instance too; the new composition "composition 1.0.1" is assigned to policy-http-ppnt-1. In that scenario the migration of an instance from "composition 1.0.0" to "composition 1.0.1" wouldn't work, because policy-http-ppnt-0 do not have "composition 1.0.1" assigned.

Solution 3: Replicas and Database support

...