inlined below
David Hull <> wrote on 09/08/2004 05:47:20 PM:
> I dithered over this. We definitely want to be able to use the
> death of a remote process as a signal to destroy resources
> associated with it.
I am much less definitive...
>
> I believe this is correct, if by "server" you mean "the thing
> managing the resource". But it reverses the usual meaning of server
> w.r.t heartbeating, where the server is the process sending out
> heartbeats so that clients can tell it's alive.
"Server" is a term you used...
> In any case, I maintain there's something to be captured here. For
> my money, though, the bigger win is with dependent objects. You
> don't want either a separate lease or a separate stream of
> heartbeats for each child resource if you can help it.
I believe that heartbeating is an important construct however I am unsure
if heartbeating is in scope for the work of WSRF. I would expect that
heartbeating would more properly be part of a "grouping" semantic
of highly available systems. Further, I would expect that the heartbeat
would be multicast to other members of the group. The creation of the
group would involve "voting", "joining" and "leaving". In this context
a strong requirement of grouping would be reliable and ordered messages.
Tom
