Howdy --  I have been thinking about a response I got from Andreas a
while back:

On Jun 15, Andreas Mueller ([EMAIL PROTECTED]) wrote:
> > > If the connection goes down, all
> > > remote subscriptions for the specific routers are deleted, except
> > there is
> > > a static route for those routers. Then they will survive and messages
> > will
> > > be stored and forwarded on the next connect. A local router never
> > stores
> > > remote subscription information persistently, hence, on startup, it
> > > doesn't know anything about remote durable subscribers. It gets this
> > > information on the first connect to the remote router.

I understand the mechanics of this situation, but not the reasoning.
My problem is that when I tell a client that I want to use a durable
subscriber to solve a problem they have, and suggest they use SwiftMQ
(assuming we don't need 2pc), I also have to explain that a durable
subscriber isn't really durable unless certain conditions are met.  At
this point the blank stares are turned upon me, and the next question
is "Well, are there any products that actually DO support durable
subscribers?".  There are always situations that can defeat a
messaging system: full disks, crashed publishers (so the message is
never generated), etc..  I guess my problem with this particular
difficulty is that I don't understand why it can't be simply overcome
by maintaining the known set of durable subscribers on every machine
that has ever published to one.  It's still imperfect but at least it
gets a lot more of the cases.  Since distributed systems are always
more complicated than they seem, there's probably some good reason why
this is a bad idea, but knowing what it is would sure be a
morale-builder for me!

Regards,

        Gary Shea
        GTS Design Consulting
        [EMAIL PROTECTED]


------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to 
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers <your-email-address>
Archive: http://www.mail-archive.com/developers@mail.iit.de/




Reply via email to