river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: SourceAliveRemoteEvent Part II
Date Wed, 06 Jun 2007 18:48:29 GMT
Hi all:

	I've been watching this discussion for a while, and I'm afraid I'm
unclear on what Mark is proposing.  Mark, could you describe exactly
what changes to the JavaSpaces or other API you're suggesting?

	I'm inclined to think that heartbeat events are already provided for by
the Distributed Event Specification (see comments below).  I could see
an "application note" to the DE spec that describes how to implement
heartbeat events, but I don't think it's reasonable to establish a
single method for subscribing to an event stream with heartbeats, in the
same way that the DE spec doesn't try to provide any standardized
registration method.

	As to whether heartbeat events should be added to the JavaSpaces
specifications (JavaSpaces07?), I don't think they are needed.  My
rationale for this opinion is that the spaces implementation is not
actually the generator for any events; the events result from actions by
clients.  In the case of a datasource that is dropping entries into the
space periodically, it's of little use to verify that the spaces
implementation is functional; what I care about is whether the
datasource is functional.  So it makes more sense sense to have the data
source drop a heartbeat Entry into the space periodically, which will
trigger an appropriate event, rather than just have the space fire off a
periodic event.

See also comments interspersed below.



On Wed, 2007-06-06 at 13:30, Bob Scheifler wrote:
> Mark Brouwer wrote:
> > Funny though that you really read those postings carefully, but you
> > Staying in the lookup service example
> > are you looking for a getState() method that would be able to reproduce
> > the complete state of all the services registered at the moment of
> > invocation, filtered using parameters matching those on the various
> > lookup methods, *together* with the last sequence number that has been
> > 'incorporated' in this view.
> I don't know if I understand you, and I don't know for sure what I'm
> looking for (it may be one of those hard problems).  If you think of
> an event registration as expressing interest in a sequence of state
> transitions, you could imagine the "last state" being held as part
> of the registration, and a getState that could query it, along with
> the sequence number for that state.  Or, if all service state changes
> as a whole could be (arbitrarily) sequenced, then state lookups on
> the service could contain the state sequence number, and events could
> contain not only the event sequence number but also the service's global
> state sequence number.
> > If the above is correct I doubt whether such a generic getState() method
> > could be designed for each and every event based service, it might seem
> > it could be too problem domain specific.
In one system I've used Multi-Version Concurrency Control
(http://en.wikipedia.org/wiki/Multiversion_concurrency_control) to
incorporate real-time events into a transactional model, where the event
notifications are generated on transaction commit.  Under this scenario,
each transaction maps to a version number, and the event object carries
the version number that is current after the event.  So you can do your
getState() inside a transaction, and have the version number included in
the returned state.  That way, you can decide whether events received
around the same time should be applied (event version > state version)
or ignored (event version <= state version).  Unfortunately I can't say
it's all that pretty.

> Yep.  I'm tending to be more interested in design pattern than strict
> API reuse to start in this area.  In hindsight it's not clear to me how
> much value the Jini uniform event&listener API has really brought us
> (could well be that it has and I just don't know it).
I find the uniform listener model allows a couple of interesting hacks. 

Case 1: For various reasons I don't like to have a lot of listeners
exported on the client side.  Because of the uniform event model, along
with the handback concept, it was easy to implement an event
multiplexer, as follows:

- Multiplexer exports a RemoteEventListener
- component that wants to subscribe to events gets a Channel from the
multiplexer.  The channel includes a handback object.  Channel is given
a local (i.e. non-exported RemoteEventListener).
- component registers for events using the Multiplexer as the
RemoteListener and the multiplexer-supplied handback object.
- Event generator calls the uniform api's notify() method on the
multiplexer's exported listener.  The multiplexer uses the handback
object to select the appropriate local RemoteEventListener object.

Case 2: The heartbeat case that we're discussing (I included sample code
in an earlier message on this topic):
- Create a RemoteEventSupervisor object that implements the
RemoteEventListener interface and has a reference to a target
RemoteEventListener object.
- Subscribe to the events using the RemoteEventSupervisor as the
- Also arrange to hit the RemoteEventSupervisor's tick() method on a
regular basis, e.g. from a timer thread.
- Event source calls notify() on the RemoteEventSupervisor.  Supervisor
resets a tick counter and calls notify() on the local target.
- tick() increments the tick counter; if the tick counter surpasses a
threshold, trigger the alarm state.

> > 1) do you think it is generic (enough) an event producer should able to
> >    notify a client of its ability to deliver events in the case there
> >    are no events to notify the client of;
> I'm not particularly convinced yet that heartbeat events should be
> intrinsic to all event registrations.
Seems like an application-level thing to me.  When it is important that
the listener know within a bounded time that the sender isn't sending,
then the event protocol should include a "heartbeat" method.  If it
makes sense to negotiate the frequency of the heartbeat, then the event
subscription protocol should include some indication of the desired
frequency.  Having an additional parameter on the event registration is
no problem; to quote the Distributed Event Specification:

"EV.2.3.4 An Example EventGenerator Interface
Registering interest in an event can take place in a number of ways,
depending on how the event generator identifies its internal events.
There is no single way of identifying the events that are reasonable for
all objects and all kinds of events, and so there is no single way of
registering interest in events. Because of this, there is no single
interface for registration of interest."

> > 2) do you think it is essential a client must be able to find out
> >    whether an event producer is able to deliver events at all;
> Neutral.
I find this useful only because the cursed Windows firewall has changed
the assumptions that we can make about the LAN;  it's now pretty common
to find the firewall blocking event notifications to the client.  But it
just irritates me to implement this kind of checking, so I can't find it
in my heart to come out squarely in favour of it.

I'll grant you that if your system boundary includes crossing a firewall
to the internet, then it's probably essential.  So far, I still
subscribe to the view that Jini's design centre is the LAN.

> > 3) do you think an event driven programming model should be possible
> >    without having the ability of callbacks from the event producer;
> It's clearly possible, so you must have meant a different question.
> - Bob
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.

View raw message