Re: JavaSpace.notify() "not reliable"

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?

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.

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.


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.
--
Mark

===========================================================================
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