Re: JavaSpace.notify() "not reliable"

Mark Brouwer wrote:
> Dan Creswell wrote:
>
>> Hmmmmm as yet I'm not clear - what are these NOOP events intended to
>> convey?
>>
>> Is it a liveness test or simply an indication that probably no events
>> have been dropped or something else?
>

So this is busting my brains a little - the below looks like a spec for
a piece of behaviour - what are the use cases?

Another question I'd be interested in exploring is how this helps beyond
me having a lease for a notification registration that I can't renew
because the related resource is unavailable and/or down?  Is there
perhaps some timeliness issue or is there some aspect of liveness that
we can't deduce unless we have this kind of event?

> Assume a RemoteEvent subclass SourceAliveRemoteEvent with the following
> semantics at the class level:
>
>   "RemoteEvent that indicates the source for which the remote event
>    listener has an event subscription is still alive, but that for the
>    given event registration actual remote event occurred within a given
>    time interval.
>
>   The SourceAliveRemoteEvent plays a role in the event protocol to make
>   assumptions about the availability of the event producer."
>
> Assume an invocation constraint SourceAliveNotificationTime with the
> following semantics at the class level:
>
>   "Represents a constraint on the maximum time in-between remote events
>    to be sent for a given event registration, also does it require the
>    first event for the event registration to be the
>    SourceAliveRemoteEvent which must be sent when the event registration
>    is granted.
>
>    In case for a given event registration this constraint is effective
>    and the time in between the occurence of 2 events covered by the
>    event registration elapses a specified time, the event producer
>    should notify the listener associated with the event registration
>    with a SourceAliveRemoteEvent. When a SourceAliveRemoteEvent is sent
>    the sequence number must equal that of the last remote event sent or
>    in case no remote event has been sent it must be the sequence number
>    of the first remote event to be sent.
>
>    In case no SourceAliveNotificationTime constraints is effective
>    for the event registration, or the value for the time argument
>    passed in at construction time equals Long#MIN_VALUE no
>    SourceAliveRemoteEvent must be sent by the event producer.
>
>    When clients set this constraint their RemoteEventListener or
>    ServiceEventListener instances must expect remote events of type
>    SourceAliveRemoteEvent to be passed in to their notify method.
>
>    This constraint can be used by a client to obtain an indication about
>    the liveliness of the event producer, the time to use depends on the
>    event rate expected and the costs involved with finding out about a
>    lost connection with the event producer too late."
>
> The above 2 classes and semantics will have the following effect when a
> client sets this constraint with a time of 30 sec for the event
> registration method and this constraint is supported:
>
> 1) the first event that must be sent immediately is of type
>    SourceAliveRemoteEvent;
>
> 2) when the time between 2 remote events generated by the event
>    source exceeds 30 seconds a SourceAliveRemoteEvent will be sent
>    with a sequence number that equals the last sequence number of
>    a remote event sent;
>
> Assuming the Jini Distributed Event Model is used and no
> SourceAliveRemoteEvent is received in a reasonable time one might write
> off the usage of this event model and switch to an inverted event model.
>

How is this different from me taking this action because I haven't
received any event at all?

> If events are being received and the time since the last event received
> exceeds 30 seconds (and a margin) one might decide to perform a
> synchronous call to the service to see whether it is alive.
>

Hmmm if I've understood you correctly: I've used this policy many a time
without SourceAliveRemoteEvents - does it need a SourceAliveRemoteEvent
to drive it and if so why?

>
> The above strategies have been used at the application layer for various
> event based services by me. It fulfills no role in finding out whether
> events have been dropped as I expect the sequence numbering for remote
> events to serve this purpose and these requirements could vary between
> service specifications. I believe JavaSpaces allows for gaps in the
> sequence numbers, for lookup service I don't know by head, but the SDM
> at least thinks when it encounters a gap that it missed an event and
> will rebuild its state for that lookup server.

Feel like this conversation may be a repeat of previous EventMailbox
discussion on Davis and/or Porter but I can't be sure and I'm hoping
someone else has the relevant references if they exist (think MB has
already stated they're now dead) - onward.....

Right so by convention we provide some kind of proxy to notify()'s.
What if we looked at some mechanisms that allowed the service that
supports the notify to offer back some kind of "source" from which to
obtain events in general?  i.e.  notify implies to me "push" why don't
we build something else to do "pull"?

Dan.

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html