Re: [wsrf] Scheduled termination, heartbeats and dependent objects

[David Hull <dmh@tibco.com>]

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.  It also seems very useful to do destruction via dependency on a parent resource.  So the idea is to have a "session" or "connection" parent resource that dies when the server dies.  Following that through, we should try to account for heartbeating, as that is a major way of telling if a remote process is alive.

However, I'm not sure I've accounted for heartbeating correctly w.r.t. WSRF.  I am still pretty sure that it's different enough from scheduled termination to be treated separately.  Partly, I'm not always sure which terms to use.

In scheduled termination, the server expects the client to send a renewal; otherwise the resource is GC'd.  In heartbeating, the server expects to hear a heartbeat; otherwise the resource is GC'd.  The difference is that the server is not expected to reply to a heartbeat.

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.

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.



Tom Maguire wrote:

David Hull <dmh@tibco.com> wrote on 09/03/2004 12:11:26 PM:

  

Heartbeating is typically used in the related case of determining
whether a particular server is alive.  The server agrees to send out
messages (generally multicast) at no longer than an agreed interval
(in some variations, the heartbeat message contains a "time until
next heartbeat" field, allowing for a variable interval between
heartbeats).  If a client does not hear from a server for more than
a given number of heartbeat periods, it assumes that the server is
down.  It's not hard to see that a variation of this could work in
the resource world: The consumer sends the provider periodic
heartbeats, and if the provider misses too many heartbeats, it
assumes the resource is no longer needed.
    

I think this confuses the use of heartbeating in a substantial way.
Heartbeating is fundamentally about determining "dead or alive" and
is not from the consumer to the producer.  Additionally, as you point
out it is typically a multicast where as in the scenario you describe
it would be a point to point message.
I do agree that there is a pattern here but I would be very careful
of calling it heartbeating.  It is more like message activation with
an LRU termination.  Specifically, it is much more like "this producer
hasn't be touched for a while (perhaps predetermined interval) so it
is subject to termination".

Tom