Re: Socket factories with JERI

Hi Mark, thanks for taking your time.

 

>Not that it shouldn't be handy to have a constraint to indicate the 

>maximum time one is willing to spend waiting for a response.

 

Actually, this constraint is exactly what i was looking for. In my
application, i have to react to physical network interruptions quickly
(< 10 seconds) In CORBA, a constraint with this semantics can be
enforced via the RoundTripTimeoutPolicy. One of the reasons i am
experimenting with JERI is the fact, that open-source JAVA ORBs either
do not implement this policy at all (Sun's ORB) or do not implement it
correctly. (JACORB).

 

Skimming through the JINI/JERI API's, i had already found the
ConnectionRelativeTime constraint, and was quite astonished that there
is no constraint with semantics similar to CORBA's RoundTripTimeout. Of
course, it is a major task to implement this semantic in presence of
multiplexing, (what may be the reason why it is not implemented or not
working in many CORBA implementations).

 

My eager hope was , that RMI resp. JERI would at least measure up to
CORBA in this respect, AFAIKS it does not. Perhaps, it makes no sense at
all to use RMI or JERI under the given requirements (detect broken
network within 10 seconds). Of course, that would make me wonder, as the
very first of the famous "eight fallacies" is : "The Network is
reliable". Perhaps i missed an essential point so far ?

 

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