Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

In the current implementation, ACM supports multi-participant with same supported element Type but different participantId, so they need different properties file.

In order to support replica, it needs to support multi-participant using same properties file.

Note: 

  • In a scenario of high number of compositions, if participant is restarting it will be slow-down the restarting action: AC-runtime will send a message for each composition primed and instance deployed to the participant.
    To avoid the restarting action, participant needs a database support;
  • In a scenario where a participant is stuck in deploying, the instance will be in TIMEOUT and the user can take action like deploy again or undeploy. In that scenario the intermediary-participant has to receive the next message, kill the thread that is stuck in deploying and create a new thread.
  • In a scenario where we are increasing the number or participants, could be useful to have different topic name for source and sink. This solution will eliminate the number of useless messages in kafka.
    Example: 
    • for ACM-runtime:
      • sink: POLICY-ACM-PARTICIPANT
      • source: POLICY-ACM-RUNTIME
    • for participant: 
      • sink: POLICY-ACM-RUNTIME
      • source: POLICY-ACM-PARTICIPANT


Solutions

Solution 1: Replicas and Dynamic participantId

  • UUID participantId will be generated in memory instead to fetch it in properties file.
  • consumerGroup will be generated in memory instead to fetch it in properties file.

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.

Solution 2: StatefulSets


Solution 3: Replicas and Database support

Changes in Participant:

  • Redesign TimeOut scenario: Participant has the responsibility to stop the thread in execution after a specific time.
  • Add client support for database (MariaDB or PostgreSQL).
  • Add mock database for Unit Tests.
  • Refactor CacheProvider to ParticipantProvider to support insert/update, intermediary-participant with transactions.
  • Refactor Intermediary to use insert/update of ParticipantProvider.
  • Refactor Participants that are using own HashMap in memory (Policy Participant saves policy and policy type in memory)

Changes in ACM-runtime:

  • 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

Changes in docker/Kubernetes environment

  • Refactor CSIT to support database configuration for participants
  • Refactor OOM to support database configuration for participants


  • No labels