Skip to content

GCP - Fix OqmSubscriberManager (topics creation algorithm) (GONRG-4680)

Rostislav Dublin (EPAM) requested to merge feature/GONRG-4680-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 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 Register 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 topic, Notification service for which they are intended.

What is the new/expected behavior?

It is necessary to change the algorithm in order to: create replicas of the topic on all brokers.

Pseudo-code of the target architecture and algorithm:

all tenants --> all brokers --> 1 topic per broker

Have you added/updated Unit Tests and Integration Tests?

[YES]

Any other useful information

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

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

Edited by Rostislav Dublin (EPAM)

Merge request reports