Skip to content

GCP - Fix OqmSubscriberManager (control topics and subscriptions creation and usage algorithm) (GONRG-4681)

Rostislav Dublin (EPAM) requested to merge feature/GONRG-4681-improve-register-subscriber-control into master

Type of change

  • Bug Fix
  • Feature

Please provide link to gitlab issue or ADR(Architecture Decision Record) N/A

Does this introduce a change in the core logic?

  • [NO]

Does this introduce a change in the cloud provider implementation, if so which cloud?

  • AWS
  • Azure
  • GCP
  • IBM

Does this introduce a breaking change?

  • [NO]

What is the current behavior?

OqmSubscriberManager (see code from line 103) checks for the presence (and creates, if not) a register-subscriber-control topic on the broker of the first tenant it comes across in order (the list of which it reads from the Partition Service). At the same time, the order of sorting the list of tenants by the Partition service is not guaranteed, which can lead to the fact that when re-creating or restarting the Notification instance, the check for the presence and creation of the topic will occur on different brokers, which will lead to duplication of the topic, confusion and non-receipt of messages, published in the Register topic by the service.

What is the new/expected behavior?

It is necessary to change the algorithm in order to: create topic replicas on all brokers and subscribe to them on all. Pseudo-code of the target architecture and algorithm:

all tenants --> all brokers (number <= number of tenants) --> 1 topic per broker --> 1 subscription per topic --> 1 subscriber per subscription per Notification Service instance

Have you added/updated Unit Tests and Integration Tests?

[YES]

Any other useful information

  • This change has been initiated by the EPAM JIRA GONRG-4681

  • This change has a paired change in the Notification service that is reflected in the tickets:

Merge request reports