Re: outrigger "I/O error reading from mux connection"

Gregg Wonderly wrote:
> Lachlan O'Dea wrote:
>
>>So, if I understand the messages you referenced correctly, this is an
>>inherent problem with distributed computing and using a transaction
>>is the standard way to deal with it?
>
>
> Primarily, what happens is that the state of the call, from JERI's
> perspective is completely separate from the state of
> the transport layer.  So, when the call is ready to return, there
> is no indication to outrigger that the return path is
> not available.  The processing is done to extract the entry from
> the space and return it.  But, of course, it can't
> return because the endpoint of the client is nolonger available/valid.
> But, there is no interface between outrigger and
> the JERI invocation layer, for this direction of call flow so that
> outrigger would know this.  Also, the calling context
> is now gone from the clients perspective.  So, there is really no
> one to be notified of the failure.

In my view the issue is a bit deeper than this. To me the above
suggests that a more clever version of JERI (which I think would
require a more clever version the java.net APIs, which in turn I
think would require a more clever version of the underlying OS level
network APIs....) would solve the problem, but it won't (though
admittedly it may make it a LOT less likely). While a more clever
JERI might be able to address the problem of what happens if the
client crashes while the client is waiting for the return, no rpc
model (by itself) can address the problem of what happens if the
client fails right after the rpc system returns to the client (
realistically there are also issues with a `clever' JERI even if
the client fails before the call returns). The issue spans any
one remote call and thus is outside the scope of what JERI (or
any RPC system) can address.

> A transaction will allow all interested parties to agree on the
> state of the entry in the space.  A write under a
> transaction would guarentee that that entry appeared in the space,
> if the commit suceeds.  A take under a transaction
> will guarantee that a failed take, such as this, can not be
> committed, and thus the entry will stay in the space and be
> made available, eventually, to another appropriate take.

--
BTW, if you want to reply to this message, please direct your reply
to the list, thanks

John McClain                                    [email protected]
Sun Microsystems, Inc.
Burlington, MA

A business that makes nothing but money, is a poor business.
   - Henry Ford

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/