CODEWITHSUNDEEP
nservicebuspublish-subscribe
jlew
jlew

Reputation: 10591

How does a second physical publisher get notified of new subscribers?

Related to this question: As I understand it, two physical publishers represent a single logical publisher must each have their own subscription queue. Using DBSubscriptionStorage allows them to have a common list of subscribers, but what happens when a new subscriber pops up and subscribes? The subscribe message will go onto one of the subscription queues and then into the database. Is there any way, short of restarting the other publishers, that they can be made aware of the new subscriber?

Upvotes: 1

Views: 385

Answers (2)

Adam Fyles
Adam Fyles

Reputation: 6050

2 Physical Publishers with Many Subscribers

Configuration

  • Every endpoint(publisher or subscriber) has its own input queue.
  • Each Publisher will be configured to point to the same shared subscription database
  • Each Subscriber will be configured to point to one Publisher input queue(this is where they will drop their subscription messages)

Processing

  1. Subscriber1 places a subscription message(M1) into Publisher1's input queue
  2. Publisher1 saves that subscription into the database
  3. Subscriber2 places a subscription message(M2) into Publisher2's input queue
  4. Publisher2 saves that subscription to the database
  5. Publisher1 publishers M1 which is placed into Subscriber1's input queue
  6. Same occurs for Publisher2 and M1

You will have to decide if all Subscribers are interested in the same messages. It is ok to have both Publishers publish the same messages as each Subscriber will only subscribed once(either at P1 or P2). You have full control on how to "load balance" the work. More information can be found here if you haven't looked at it already

Upvotes: 1

Jonathan Oliver
Jonathan Oliver

Reputation: 5267

You have a couple of options. One of the easiest is to have each of the separate physical publishers pointing to a single physical subscriber/subscription database.

Another really good way to handle it is with database replication. The only problem with replication is that it's inherently "one way". Even so there's a really interesting project for MySQL called "MySQL MMM" that seems to be a perfect fit for this scenario.

Finally, you could potentially have your own subscription storage using something like Membase which is a persistent, replicated key/value store.

Bottom line: you can have a single subscription database which is the easiest, but you have a failure point. Or you can have a replicated subscription storage. The replicated storage will ensure that all nodes have a list of all subscribers.

Upvotes: 1

Related Questions