Let me explain what I mean. Imagine A subs to event b. In such case A pubs event a. B subs to event a. In this case B subs b. This is a full-blown circle. How does a pub/sub cycle deal with such fringe case? I haven't tested it because I'm yet to write my own pub/sub engine in Java or JavaScript. In fact I'm not sure if I understand it correctly that's why nothing in Google came up after I searched fr these keywords "pubsub" + "loop" + "recursion".

Let me draw an ASCII diagram.

A <-----------> b
|               |
|               |
|               |
a <---------->  B
  • If you make an infinite loop then you get an infinite loop. I don't think you can change that? Of course if you program "do X when Y happens" and "do Y when X happens" then you get an infinite loop. – user253751 Jun 30 at 17:58

Consider hanging the design of your events:

simplistic : a publication number that you increment. and drop the event when it reaches some number. Worked on a reactive client server system I made years ago.

Better: keep the parent event a inside b when published. if A saw an event triggered by A it would drop processing the event.

This is commonly used in large scale distributed . it makes debugging what's going on a lot easier too for debuggers of B or A., especially if they're separate services, servers or microservices.

| improve this answer | |

It depends on the tech involved, but in general, messages flood the hell out of each publisher and you quickly find out where the limitations of your system lie.

Subscribers that take the most time/cpu won’t keep up with the flood, and will either keel over due to the load or accumulate pending messages until something in the subscriber queue runs out of resources and breaks.

In the case of synchronous in-process events (like .NET’s events), it will look like your standard faire infinite loop - though harder to identify and harder to debug.

Instrumentation should catch the exponential growth, but probably not quick enough. Depending on the situation, throttling can be put into place so the pub isn’t flooded with messages - but there aren’t great failure modes for that. And this sort of flood can look very similar to normal traffic spikes due to say... a Black Friday sale.

For internal only events, documentation and communication will create hierarchies of events so there aren’t cycles. Humans will make mistakes of course.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.