Re: AW: Socket factories with JERI

Hi Martin,

Cornelius, Martin (DWBI) wrote:
> Hello Mark,
> 
> thanks for this really interesting information. 
> 
>> Also  I don't  expect a  timeout constraint  to be  very accurate,  making > it  a soft[*] constraint. I don't expect people  to make a decision
>> between a  timeout of 100ms versus 150ms, but more as a mechanism to
>> protect itself from hanging on a system it can't influence and to specify 
>> the range in which it should  return.
>> I expect people to use a time-out constraint with a timeout of 500ms or 
>> 1sec for the  general call  that would  take ~50ms.
> 
> With respect to our current project, your expectations are exactly
> correct. As i already wrote, we have realtime requirements: If a remote
> call, that normally takes ~50 millisecs, does not return within ~2
> seconds, the results of that call are useless in our system. We must
> assume in this case that the network or the called server is broken, and
> we must immediately react to this failure. We also want to free
> ressources used by this remote call immediately (i.e., close OS sockets
> and make objects eligible for GC)

I agree with the part that a remote method invocation that doesn't
return within the time limit should free resources at the client side,
but I think from a server side perspective to act properly seems to be
much more difficult, especially if you bring DGC into the picture. The
fact a remote method invocation can't complete in a certain time limit
from the viewpoint of one client doesn't always mean that it can't be
completed from the viewpoint of another client, e.g. due to another
network route that client has, or fill in some other cause.

My need for this constraint has been one to be able to abort remote
method invocations due to dead-locks at the other side or to get an
indication something (which could be anything) might be wrong and for
which I don't want to code the logic myself to detect that. It is of
course possible to create your own notification logic when a round trip
time exceeds a certain threshold but beside the amount of boilerplate
code it would take it doesn't help much with freeing resources (thread
used to make that remote method invocation).

> BTW, i have just coded SocketFactories for 'traditional' RMI that use
> nonblocking NIO and select() for reading and writing and this way
> implement read and write timeouts on sockets. This way, i can prevent
> the client as well as the server from hanging if anything fatal happens
> to the network or to the peer machine during a remote invocation. I'm
> now going to modify this factory to make it usable with JERI, perhaps
> this provides a usable workaround.

The problem I see here is that read timeout is a very bad prediction for
the round trip time you expect, it will detect a broken network, but if
you need it for detecting the liveliness of your server it doesn't do a
good job. Also will it be uniform for all the remote method invocations
you make to the server and that doesn't seem that right.

>> Improvements to the Jini core are supposed to be developed as part of the
>> Apache River project and and any input for ideas to materialize is
>> welcomed.
> 
> I looked at http://incubator.apache.org/river/roadmap.html and
> subscribed to the developers mailing list of the project. For our
> current project (that is scheduled to be completed within 2008), the
> detection of broken cables/servers within a few seconds is an absolute
> knockout requirement. Do you expect that river will support 'round trip
> timeout constraints' in this timescale ?

Sorry Martin, I'm not going to burn my fingers at making forward looking
statements with regard to what kind of issues will be tackled in 2008 at
the River project. There are other people who are better qualified at
making statements about the amount of work and complexity involved and
whether it is 'a good thing' anyway (Bob?, Peter?). And it will also
require the help of those who feel the need for incorporating it, it has
after all become an Apache Project based on volunteers.

My personal opinion is still that there should be a mechanism that
allows you to specify a timeout round trip constraint (regardless 
whether it should be a constraint or something else). Please add an 
issue to River JIRA as I believe there isn't one.

> Finally, i'd like to raise some general, somewhat heretical
> questions.
>
> Just having read the report about the JINI based 'Neuromancer project',
> which was discontinued, i'm asking myself: If we are looking for a

I think it is normal for Sun Lab projects that these finish after a
while as with most research projects. Some of them might get a follow up
and materialize in a product or something else and some of them are just
to elevate the general knowledge related to a problem space. I think one
can't make judgments about the applicability of Jini based on the
Neuromancer project, but no doubt Jim Waldo will correct me if I'm wrong.

> networking technology to be deployed generally in our (more or less)
> embedded products, that should survive one decade, could JINI/River be
> the choice? Who is supporting this technology (SUN any longer ?), and

Jini already survived for over 8 years now while it has been declared
dead each and every year. And it is interesting to see that the
underlying technology is sound and looks advanced compared to other
technologies that see the light these days. The Jini team seemed to have
taken the time to do things right, i.e. implement things only when they
knew how to do it. So I believe that Jini will live at least another
decade, if it were only to implement the things they didn't know how to
do in the past :-). *But* it can't be denied that Jini is currently in a
transitional phase now that Sun handed it over to Apache and that things
are not going as smooth yet as they should go.

The Jini core is lacking in certain areas, such as usage for Internet,
where NAT, proxy, HTTP(S) is the *only* standard and that should be
fixed (which can be done) as soon as possible IMHO.

If Jini at this point provides what you need I would say it is a safe
bet, there are also other projects that ease working with the core
technology itself. But if you really need stuff that is missing I would
wait until you get some indication that those missing pieces will be put
in place or you should rely on implementing it yourself.

> who is actually using it? Are there any 'reference' projects one could
> cite to convince coworkers or even managers? I'd really appreciate any
> hint or report about this issues, regardless it's tenor.

There are lots of people using Jini although it ain't highly visible,
some of those you can find here
http://www.sun.com/software/jini/news/success.xml
. In the financial services industry it is used a lot I can tell from my
own experience and maybe relevant to you Nedap is using it based on this
presentation at the 8th Jini Community Meeting 2004
http://www.jini.org/files/meetings/eighth/presentations/Wegman/Wegman.pdf

I realize that it is easier to hand over a lot of references that will
convince others, but one must not forget that it is hard to beat a
competitor by doing exactly the same tricks he is doing (excluding
marketing and sales of course ;-)

Hope this helped,
-- 
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]