Wow, I stand corrected. I did not understand that "view" concept. I see
how that is very powerful and useful. This is definitely something that JMS
will not be able to provide. I'm going to have to research it further.
Thanks,
Hiram
----- Original Message -----
From: "Sacha Labourey" <[EMAIL PROTECTED]>
To: "JBoss-Dev" <[EMAIL PROTECTED]>
Sent: Friday, March 09, 2001 1:57 PM
Subject: RE: [jBoss-Dev] CL: Clustering, let's get started
> > I wasn't aware that JMS could
> >
> > a) allow you to modify/customize the protocol stack
> > b) provide notification of members that joins, leaves or crashes
> > c) atomicity
>
> Exactly. Furthermore, it may also give you synchronous view group
> communication i.e.
> "- Agreement: correct processes deliver the same set of messages in any
> given view
> - Integrity: if a process P delivers message m, then it will not deliver m
> again
> - Validity: correct processes always deliver the messages that they send.
> If the system fails to deliver a message to any process q, then it
notifies
> the suviving processes by delivering a new view with q excluded,
immediately
> after the view in which any of them delivered the message.
>
> In a view-synchronous system, the delivery of a new view draws a
conceptual
> line across the system and every message that is delivered at all is
> consistently devlivered one side or the other of that line. This enables
the
> programmer to draw userful conclusions about the set of messages that
other
> correct processes have delivered when it delivers a new view, based only
on
> the local ordering of message delivery and view delivery events." (from
> Distributed systems, concepts and design, Coulouris-Dollimore-Kindbert,
3rd
> ed., Addison-Wesley)
>
> Some approximate definitions:
> - a group is a set of processes
> - a view is a set of process
> - delivering a message means receiving it
> - delivering a view means receiving the new set of processes that are
> corrects (i.e. alive, ...)
>
>
> Consequently, it is possible to exchange information in a group (new JNDI
> name binding for example...) and be sure that everyone correct will
receive
> it (in the same order if necessary). As each view change (v0, v1, v2, ...,
> vn) and message (m1, m2, ..., mn) is numbered, it is possible for a
process,
> when it wakes up, to ask the group to get all updates > mi (i is the last
> message he got before collapsing). Furthermore, such a system needs to
> detect when a system has failed (to deliver a new view), which why such a
> subsystem is present in javagroups to detect these potential failures. The
> algorithm that determines which view is valid, ... is distributed and
> fault-tolerant in itself : if the "master" dies, an election automatically
> takes place to determine the new master.
>
> I understand it is a bit a quick introduction... ask if you have some
> questions!
>
> Cheers,
>
>
>
> Sacha
>
>
>
