Support for Backup Publisher and Subscribers

[ajithnn]

Introduction

Judo has 2 major interfaces

1. Client - this is the primary Subscriber interface
2. Publisher - this is the primary Publisher interface

We have implemented multiple protocol wrappers , each protocol implements the above interfaces.

Judo can be used by calling the NewClient function with a JSON defining the configuration for a subscriber or a publisher. This initializes the above interfaces and starts listening to messages.

Problem statement

Irrespective of the protocol an application uses there is always a possibility that the message broker / central server of the protocol is down or the intermediate network is down. This can cause message delivery delays or Message loss.

Judo solves the Message loss issue by allowing persistence to be enabled, even when the underlying protocol does not support it (eg: redis). With persistence we can re-send the message once the network/connectivity is back. But the delay problem still exists. For certain use-cases a delay will not be acceptable as the needs of the application are real-time.

Solution

To workaround the delay issue , we propose a Primary and a Backup protocol support through judo library.

• Create a New Class(struct) called PriamryBackupSubscriber
  • This object takes 2 JudoClients
  • This object also Passes a callback to both the subscribers
  • This callback defines the isDuplicate logic and the MessageID extraction logic
  • This callback calls the appropriate OnMessage of either the Primary or Backup or Ignore the message
• Create a New Class(struct) called PrimaryBackupPublisher
  • This object takes 2 Judo Publishers
  • This object defines a Publish method when called it will call both Primary and Backup Publish methods
  • This object defines a Unique Message ID and adds it to the message on both Primary and Backup Publishers

@SunilSKamath4s Can you go through this and add questions if you have any ?