Hi Dan,
I redirect this discussion to river-dev for reasons stated before, so
please if you are going to respond only to river-dev.
Dan Creswell wrote:
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?
I think there is one overarching use case and that is that you can't
draw any conclusions from not receiving any event. A constraint to
specify you want an immediate first event and at least one event for a
given time interval provides you the ability to start finding out about
the cause of not receiving any event after a defined elapsed time.
Each event protocol I've designed so far had this notion (eventually),
one of these use cases you will see in my response to Greg T.
It is like managers who always like it when developer give them a status
report without having to ask for it every day. Not receiving a status
report alerts them and they will investigate. Or when you are on
holidays your mother still likes it when you call her to tell that
everything is OK ;-)
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?
Correct, the liveness guarantees differ from the period for which I'm
granted the lease. The lease is a contract from the lease granter to me
that I can use it resources/service for a particular time, the event I'm
talking about is a quality of service aspect that helps me in making
decisions whether I should start some investigations about why I don't
receive any events. Is it because there are no events (which is quite
common) or because something broke in the event delivery chain.
E.g. in case of the FX events in the other posting I would set the
liveness duration to 10 seconds while my lease will be 5 minutes.
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?
This constraints enforces that for a given event registration it should
send a SourceAliveRemoteEvent even in the case there is no actual event.
Of course each event protocol could introduce such a 'ping' event
which would bring it on par, but given its general applicability I think
it is worth to factor this out and make it a QoS constraint.
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?
Common pattern, as you indicate you have used this policy many times.
You do it, I do it, probably many others do it. Why not standardize the
pattern allowing for utility classes we write to rely on the (optional)
existence to teach and explain the common pattern as part of distributed
events.
If these stay yours and mine proprietary solutions, they stay what they
are, yours and mine solutions with yours and mine toolkit around it.
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.....
Sorry, I did a search on the internet but the mailing lists are not
archived, I only have them in my mailbox. Although I brought up the
inverted event model as well, which is indeed a follow up of that
discussion, the 'alive' constraints isn't.
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"?
Although I didn't do the complete analysis and I have no experience with
developing and implementing a pull API, looking at
MailboxPullRegistration which allows you to pull for events, you see
that it is not blocking. Often in case of events you want to be notified
as soon as something happens (reactive programming model), so pull
without a timeout is pretty useless for these cases. Assuming you have
multiple event registrations to a service (event kinds) and we had a
blocking pull based API, how are you going to multiplex these over the
same connection or should you have a pending request for each of these.
Hiding the actual pulling as an implementation detail of your smart
proxy allows the service or framework implementor to do things you don't
want to bother the client with or are not possible given a pull API.
To summarize (in I think as many words ;-). The ultimate notion for an
event is that you want to be notified of the occurrence of some kind of
event in the source and want to react on that. Of course people could
pull themselves for these occurrences, but pulling for events in a
scalable way taking concurrency guarantees into account is less trivial
than it seems. Why not take advantage of the existence of mobile code,
why not hide the complexity involved with pulling in the specialized
proxy and to convert it there to what they ultimately are ... events.
When we have 2 types of delivery mechanisms for these events, each with
their own characteristics but from the viewpoint of the client very
similar. In the end it is a remote event you receive, all code based on
remote events can continue to work [1]. From a framework perspective, as
has been done in the JSC Specification, you are just an ordinary event
producer and that API to publish your events is the same for both event
models.
[1] this is a very small lie, it requires a few extra lines of code
because the listener for events is a local listener versus a remote
event listener.
--
Mark
