river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Wed, 06 Jun 2007 08:56:20 GMT
Bob Scheifler wrote:
> Mark Brouwer wrote:
>>> I don't particularly like having two different ways to express
>>> interest in events.
>>
>> Activating SARE
>> over the event protocol specified as part of a service specification is
>> done by setting an invocation constraint, no modification of the event
>> registration as is currently done.
> 
> That's exactly the problem.  Interest in events is normally expressed in
> arguments to the registration call, but interest in SARE is expressed
> separately via a constraint.  There shouldn't be two mechanisms used
> in the same remote call to express interest in events.

I don't see it as black-and-white as you do, partially I came up with
this to keep current API as it is and to make it optional. I'm
indifferent at this point if it would be supported by a 'stronger' API
mechanism.

>>> Your main purpose seems to be finding out if callbacks are possible,
>>> to decide whether to switch to an alternate event model.
>>
>> Also I would like to express that this feature was not
>> my main purpose
> 
> Your May 15 message implied the opposite to me.

I see, that posting captured the work on the inverted event model (very
old) and the specification for the SourceAliveRemoteEvent and
SourceAliveNotificationTime constraints (one day old) and for me
suddenly it all came together. Maybe I was a bit too enthusiastic about
the reachability aspect, but since then this thread did a good job of
taking the joy away ;-)

Funny though that you really read those postings carefully, but you
always seem to miss direct questions like "whether an inverted event
model is desirable?".

>>> For the goal of finding out if callbacks work, it seems preferable to me
>>> (in the abstract) to have a single synchronous callback occur during
>>> event registration, and have registration fail if the callback fails.
>>> Or to have a separate "make this callback" method on the service.
>>
>> That would be a way too, although this seems to require the client
>> registering for events to pass in a method to be intercepted by the
>> smart proxy.
> 
> The existing event listener could be called.

I think I don't get the picture yet. Are you saying the current
RemoteEventListener ( notify(RemoteEvent) ) is going to be called by the
event producer to find out about reachability before granting the event
registration? If that is the case that would mean the remote event
listener would have to consume a 'throw away' event. If it is not the
case are you envisioning a subclass of RemoteEventListener that has a
probe method on it, such as the hack below.

/**
  * Extends RemoteEventListener with functionality to test for
  * reachability of the client and to be able to receive notifications
  * of the liveliness of the event producer in the case no events
  * occurred for the associated event registration.
  */
public interface RemoteEventListenerX extends RemoteEventListener {

     /**
      * Invoked by the event producer before an event registration is
      * granted for the listener to be registered, or at any time the
      * event producer finds it opportune to test for reachability or
      * when it is requested by a quality of service aspects effective
      * for the event registration this listener is associated with.
      *
      * @param handback handback object as passed in at the moment of the
      *                 event registration
      *
      * @throws RemoteException
      */
     void probe(MarshalledObject handback) throws RemoteException;
}

I agree though that it is likely more elegant if an event registration
for a RemoteEventListener fails if callbacks are not possible compared
to my model where the client gets an event registration at all times.
Although it will be important to make sure security constraints are
uniform for both methods (notify and probe).

But there is another viewpoint possible (assuming there would be an
inverted event model) and that is to say well the registration for
receiving events represents something completely different as the
ability to receive those events.

I register for events (with RemoteEventListener) which is granted by the
event producer even while currently it can't reach me. If I find out
(through SARE) that I don't get the mandated first event in a certain
time, I can decide to switch to an inverted event model, no need to try
to obtain a new event registration.

>>> part of this being, when you know you've lost an event, being able to
>>> call some form of getState that would include an event sequence
>>> number in the returned state, so you can figure out whether new
>>> events are before or after your getState call.
>>
>> The problem I see with this is that we have two execution paths
>> with no end to end synchronization between them (we can't stop notifying
>> as soon as we intend to make the getState call and we know for sure
>> there are no events in transit and the latency for each path). Therefore
>> I'm very unsure of how to make decisions based on the outcome of 
>> getState().
> 
> The problem you describe is what we have today.  In a LookupCache,
> when an event is lost, a fresh lookup (aka getState) is performed,
> but it has no sequence number to correlate it with ongoing events,
> so there is a lot of convoluted code and thinking and bugs that go
> into trying to correctly process events that occurred before the lookup
> but arrived after the lookup.

I think slowly I get what you initially wanted to make clear, as I know
the code you are referring too. 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.

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. Problem here is (currently) the
initial state retrieval methods have no relation to the registration for
notifications, i.e. I could register for events with a completely
different template as being used for doing the lookup (although not likely).

Lookup service is a service that can be described as a service that has
ordinary methods to obtain a view on some state and where events are a
pure optimization. You can live without them although it can have severe
consequences for bandwidth usage and the accuracy of your view of the djinn.

I've written similar services such as one that lists all (ongoing)
financial transactions matching certain templates and the view (list) is
updated through events, (often called deal blotters) so I resonate with
the problem.

But I've also written event based services that even don't have the
ability to obtain a bootstrapping state but for which ordering and fast
response are essential (so polling is no workable model) to make proper
decisions. An example would be a client who gets streaming foreign
exchange rates such as EUR/USD (what you get represents 'sort of' the
state in the market). For these type of services I'm not very interested
in recovering, I'm particular interested in having confidence in its
correct working (a heartbeat) of the event delivery, something SARE
covers and for which I hope that we can agree that ping doesn't
represent a proper way to validate the path from sender to receiver.

I think what makes these (meant broader than just you and me)
discussions often hard is that we sometimes talk different language that
are mainly dominated by our (limited) experience and problems we've seen
in the past. So far I haven't got a clear ACK [1] for some of the
underlying reasons I want to have something as SARE. Maybe I'm wrong in
the fundamental assumptions that makes any discussion about SARE futile.

Therefore I have a few questions for each to answers (sorry on forehand
for any bias in the questions, rephrase if you like):

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;

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;

3) do you think an event driven programming model should be possible
    without having the ability of callbacks from the event producer;

If all or at least some of these questions get a positive answer we can
work on a way how that should be incorporated in API/protocol, etc. If
too much negatives I think it is better to stop this discussion and find
something we can work on.

[1] something I learned (the hard way) from women is that it is really
important to acknowledge a problem. The recurring fault I probably made
here is that I also went straight to the solution ;-)
-- 
Mark


Mime
View raw message