Most of the responses seem to address making sure the 
intermediary/broker doesn't lose the message. Generally speaking, 
that's not where the problem lies. Open source and commercial 
products are largely rock solid in this regard--and performance 
generally is not a problem (except when someone publishes a few 100+ 
MB sized messages!).

The problem is usually with the end points, where the handshake 
between broker and end-point says "got it, thanks" but then the end-
point fails for some reason. Another concern is in "reconnecting" 
publisher-side info with subscribers' side info for correlation and 
tracking. I've seen very elaborate schemes employed to track and 
matchup both sides, trying to proactively detect when and where a 
process drops off.

Many times, the relationship between publisher and subscriber is more 
or less 1-to-1. For a given message, there is 1 publisher and exactly 
1 subscriber. Much complexity introduced for anticipated flexibility 
that is never used.

I see this pattern repeated in many places, hence my position on 
pub/sub. To me, pub/sub seems generally misused and misapplied.

This is not intended as an indictment of all intermediated 
interactions, nor a claim that pub/sub is a Bad Thing in all cases. I 
just think pub/sub is used more than it should be.

Of course YMMV. :-)

-Rob

--- In [email protected], "Udi Dahan" 
<[EMAIL PROTECTED]> wrote:
>
> I've put a short article up on my blog about the whole issue of lost
> notifications and pub/sub.
> 
>  
> 
> Lost <http://www.udidahan.com/2008/12/07/lost-notifications-no-
> problem/> Notifications? No Problem.
> 
> In it I outline how the various performance and availability 
> characteristics of different services may cause a subscriber to 
> miss a notification and how to feed that back into the design 
> process to get a service ecosystem where notifications (different 
> kinds than before) won't be lost or missed.
> 
> Interested in hearing feedback, especially on how this may impact 
> the issues of monitoring and management Rob raised below.
> 
>  
> 
> -- 
> 
> Udi Dahan - The Software Simplist


Reply via email to