Re: Socket factories with JERI

Hello Mark,

thanks again for paying so much attention to my dumb newbie questions.

> 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.

Of course it is not the golden bullet i really needed, but as far as i
thought until today the best i could get (see *** below). The only other
solution i can currently imagine is to run a separate timer thread,
which would try to terminate the call by interrupting the calling thread
once the round-trip-timeout happens. Not really elegant, and i'm also
suspicious if this will work at all. At least it would be necessary to
have JERI use NIO socketchannels, because read and write on
'traditional' Java Sockets are not interruptible.
(***) Unfortunately, the 'porting' of my NIO based RMISocketFactory to
be usable with JERI was not sucessfull at all, i'll describe my problems
in a separate post to this list.

> 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?).

Well, having been burnt myself quite often i fully understand that. I
will pay special attention to this list w.r.t this issues.

> 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.

Personally, i would really appreciate to volunteer River development, as
IMHO it is a very promising architecture. However, being a 'simple
hackney', i'm not in the role to decide that. Future will show...

> 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.

I'll try to figure out what JIRA is and how to do that, hopefully i get
it right ;-)

> 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.

Skimming through the API i got the impression that most of this
standards are already supported (e.g. by the various implementations of
net.jini.jeri.Endpoint). Could you briefly explain what Jini is
essentailly lacking in this area ?

Kind regards, Martin


 
************************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
************************************************

--------------------------------------------------------------------------
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]