[FOLIO-2608] Should publishing a message fail if there are no subscribers? Created: 20/May/20  Updated: 03/Feb/21  Resolved: 03/Feb/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: TBD
Reporter: Marc Johnson Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: potential-decision
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to MODFEE-54 Publish event when an account with lo... Closed
Sprint:

 Description   

At the moment, publishing a message to mod-pubsub fails if there are no subscribers.

The impact of this is that subscribers have to be developed, deployed and enabled prior to publishers otherwise publishing will fail, unless they either ignore all failures to publish messages or try to only ignore this specific failure.

Was this the intended behaviour? If so, I'd like to understand why, as it seems counter-intuitive to me (I shall share my thoughts in a comment below).

Taras Spashchenko VBar Oleksii Kuzminov Mikhail Fokanov Jakub Skoczen Craig McNally I'd appreciate your thoughts on this question.



 Comments   
Comment by Marc Johnson [ 20/May/20 ]

Personal thoughts

My understanding of the intent behind the publish-subscribe pattern is to decouple publishers and subscribers. I think an implicit part of that is that there should not need to be any subscribers for a message to be successfully published (to no one, if transitive).

publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

from Wikipedia (emphasis my own)

Externally failing publishing of a message if there are no subscribers creates an implicit coupling between the publisher and at least one subscriber, because the subscriber must be present for the publisher to function as intended.

To me, it is counter intuitive that a message has to be subscribed to before it can be published. I understand why it's desirable for subscribers to be present before any messages are published, so that no messages are missed. However, this decision means that no publisher can be enabled for a tenant, without knowing a subscriber is present, unless these errors are acceptable.

The workaround, to ignore this particular failure, is brittle and increases the coupling between the publisher and mod-pubsub and introduces the possibility that genuine failures are missed or ignored.

Comment by Taras Spashchenko [ 22/May/20 ]

I think there is some misunderstanding here.
Currently, there is a bug, that prevents publisher registration if there are no subscribers registered yet. And FoliJet team has created a Jira issue for that.
So the possibility to register a publisher should not depend on subscribers' existence.

Regarding the inability to send event if there are no subscribers for that it was a deliberate decision. The main goal is to do not waste resources that are required to store all those events that never will be delivered.

Comment by Marc Johnson [ 25/May/20 ]

Taras Spashchenko Thank you for responding.

I think there is some misunderstanding here.

There is every chance I have misunderstood the current behaviour or the intent.

Currently, there is a bug, that prevents publisher registration if there are no subscribers registered yet. And FoliJet team has created a Jira issue for that. So the possibility to register a publisher should not depend on subscribers' existence.

Oh, I was not aware of this issue. Please could you refer me to the JIRA so I can learn more about it.

Regarding the inability to send event if there are no subscribers for that it was a deliberate decision. The main goal is to do not waste resources that are required to store all those events that never will be delivered.

I can very much understand not wanting to waste storing messages that won't be delivered to any subscribers. (One trade-off with that is a reduction in the ability to diagnose issues that might occur)

What I am yet to understand is why this decision needed to be public, in the sense that the client is informed, rather than private within mod-pubsub.

By making it public, either the publisher has to know that subscribers are present (which increases coupling between them) and otherwise refrain from publishing, or it needs to apply special case logic to ignore this error (which is brittle and might hide genuine errors).

Does that make sense? Please can you help me understand the intent behind making this decision public to the client?

Comment by Marc Johnson [ 03/Feb/21 ]

Closing as pre-dates the new decision making process and has not progressed

Generated at Thu Feb 08 23:21:55 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.