Bob Scheifler wrote:
Mark Brouwer wrote:
The idea has 3 aspects:
1) the SourceAliveRemoteEvent (SARE) protocol is triggered by a
QoS invocation constraints set upon registration;
I don't particularly like having two different ways to express
interest in events.
I can't completely place your remark as expressed above. 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.
I can understand that doing this as a constraints is maybe a bit hard,
but so is setting all the other constraints related to security and
time-outs. Setting constraints or super positioning can be made easier
through some utilities but this is for another topic.
2) the source must send a SARE as the first event (this is helpful in
finding out whether callbacks are possible);
Your main purpose seems to be finding out if callbacks are possible,
to decide whether to switch to an alternate event model. It's not
clear to me how common it is or will be to have deployments where you
don't know if callbacks will work. It's also not clear to me why you
wouldn't just use the alternate event model first.
Ok, from your response I assume you took into account there is such a
thing as an alternate event model, this has not been my assumption when
specifying this. Also I would like to express that this feature was not
my main purpose, in fact while specifying as part of the discussion I
came up with this addition and thought of it as a nice side catch (or
whatever you call that in English).
Assuming there is an alternate event model I believe that due to the
fact an alternate event model will likely be based on polling it scales
less, so if callbacks are possible you might want to prefer that
model over the alternate one.
But I admit that although Seven supports both event models most of the
time I've used the alternate one, but in many cases for other reasons
than reachability, for brevity I wont expand on that. The main exception
is the lookup service running on the JSC API as it requires additional
configuration of the SDM to use the alternate event model (modified
version only available through Cheiron) and a lot of clients only have
the SDM supplied as part of the JTSK to their avail.
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. It even seems to imply by default this requires a smart
proxy while the current event registration could be completely coded at
the server side. And probably it will require more round-trips for
getting the event registration.
Another issue to consider here is that the separate callback method
required introduces the 'requirement' that security constraints must be
in sync (uniform), when this is not the case it might turn out the
callback succeeds, but the notifications fail.
Therefore to me it seems a first ping event gives me more guarantees the
source is able to deliver events to me.
3) the source should send a SARE in case a certain time after the last
remote event sent has elapsed.
It has long seemed to me that one of the deficiencies of the event&leasing
APIs is that you can't get back the current event sequence number in the
return from your event registration lease renewal. Another is that we
don't have a solid theory in general about how to recover from lost events;
In my usage of SARE like mechanisms the lease was often an order larger
than the time-out, e.g. SARE time-out of 5-10 seconds and lease times of
10 minutes. Getting the current sequence number as part of the lease
renewal seems to complicate the client side a lot as this data has to be
correlated and in case of a high event rate it is very interesting how
to handle any difference.
I would like to make clear that I'm not that concerned about lost events
if they are of the sporadic type. I'm mostly interested in finding out
whether the omission of receiving events is due to the fact there are no
events or that something caused the delivery to stop. This has been the
recurring theme for many services I was involved with ('real time'
financial data for which timely delivery is key, often the remote events
had a time stamp [1] in an NTP based network).
If I can't get some indication the source is alive and kicking I'm not
that concerned as a client for the reason why, that is up to the people
in the NOC that I just notified. Most times I just will fall-back to my
backup event based services. I realize that these type of services are
not the typical ones currently standardized such as the lookup service
for which I have no idea as of yet about the time-out I would set for
SARE, Long.MAX_VALUE or something near the lease time as I still think
that a check based on the path from A to B doesn't have much value for
the path from B to A (not taking your getState() into account).
[1] I think a timestamp would be a good addition for SARE.
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. I wonder if solutions
to either or both of these would be more useful than SARE.
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().
--
Mark
