river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: JavaSpace.notify() "not reliable"
Date Wed, 16 May 2007 13:11:29 GMT
Mark Brouwer wrote:
> Dan Creswell wrote:
>>> Of course all of the above can be developed for each specific event
>>> protocol, but in my humble experience that has proven to be a repetitive
>>> task which requires less than trivial logic at the event producer
>>> side. The watchdog logic at the client side is repetitive as well and a
>>> lot of people dismiss remote events as being unreliable while I think we
>>> have the means to alter that notion.
>> Mmmmm, I'm not sure we should alter that notion.  There's more than just
>> the software at work here.
>> When we talk about events being unreliable we don't just mean that
>> services go down etc.  What we're saying is something like:
>> "You need to figure out what your failure recovery processes are and
>> design them into your system at human, code and hardware levels".
>> One thing you might do is the kind of thing you're describing but it's
>> not the whole picture.
> I don't disagree here Dan, reliability covers a lot of ground. But with
> regard to events it is often the fact you don't know whether an event
> occurred or that any of the above occurred that is inferred by it.
> Otherwise we should label synchronous invocations as 'unreliable' too,
> which of course we know are unreliable too ;-)
>>> For that matter I believe the pattern is that common that I consider it
>>> a proper (optional) addition to the Jini Distributed Event Model and of
>>> course together with the 'inverted' event model. When we 'standardize'
>>> this practice we can developed the client side utilities, we can have
>>> framework support for the server, but of course you are also allowed to
>>> do all the heavy lifting yourself ;-). We can write articles about best
>>> practices, etc, etc. Bottom line is that we should be able to create
>>> event based solutions for which our friends in the 'you want data, I
>>> have data' have to write oh so many lines of error prone code to get the
>>> same level of robustness (or information to base decisions upon).
>> No issue there but I'm not clear on just how deeply baked in this
>> support needs to be.
> Fair enough questions. To me some things only have value when we
> 'standardize' it [1] (either optional or mandated) as part of the core
> of Jini. Standardizing allows me to build upon or for something that is
> larger than the world I'm part currently part of.
> The LUS that comes with Seven does things for people who need to cross a
> firewall, but it is a propriety solution as it only works with the SDM I
> supply as part of the Seven Suite. This is a situation I don't like for
> various reasons and some other people also don't like because they want
> to be able to swap. Some end up using it anyway because when the pain is
> hard enough 'principles' fade away ... but it is far from ideal.
> If it turns out nothing needs to be 'deeply baked in' I really question
> the value of continuing with Jini as to me that would mean it is
> finished. It might be other tasks are more important but so far it is
> rather silent with ideas and I guess nothing prevents from discussing
> ideas while we are awaiting the code, I grew a beard by the way :-)
> [1] soon I'm going to stop with these quotes ...
>>> As a last note, I think the addition of such a protocol would be
>>> particular useful for ServiceRegistrar. Not only would this enable a
>>> test for whether callbacks can be received (Jini Distributed Event
>> Could I not test the ability to do callbacks with something like:
>> (1)    Register a notify for a special test proxy I'm about to publish
>> temporarily.
>> (2)    Register my test proxy.
>> (3)    See if I get an event.
>> (4)    If I got an event I'm all done otherwise I'll try a few more
>> times.
>> etc.
> The above assumes that you can register your proxy with the same LUS as
> the LUS from which you want to receive events. This already takes a lot
> of assumptions with regard to security e.g. The trust relationship for a
> pull versus push event model can be completely different.
> But of course we can work our ways around everything what is missing at
> this point in the Jini Specification, but at what costs and what are the
> benefits compared to standardizing a common pattern.
> I'm not saying what I came up with is sound, although it represents the
> pattern I developed when writing a lot of event based services and
> turned out to work quite well.
> But I hope that if at least the problem resonates with people we can try
> together to come up with something that takes all roadblocks into
> account and the improve the current situation.

Sure, I'm with you on that - I guess maybe I'm coming from a more
organic position where we do something simple that won't solve all
possibilities and see what happens from there. [1]

[1]  The age old let's get some feedback Dan mantra.


View raw message