...
- 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 we need proper participant replication 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
- for ACM-runtime:
...