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

John W. F. Mcclain wrote:
> Gregg Wonderly wrote:
>>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).

I kind of thought about that perspective as I wrote that!  I sat for a minute and tried to think of anything clever that
might help.  But, I couldn't think of anything with the current API design.

Using a RemoteListener interface out of outrigger, the notify() call would encounter a RemoteException that you could
decide would mean to put the value back into the space.  However, we know that could be the wrong thing to do as well.

In the end, transactions are currently best so that the invisible operations that fail don't lead to unexpected results.

And, its blocking operations for any service, not just outrigger that have this failure mode!

I would like to encourage some discussion on this type of failure to see if we can find a different pattern that allows
more errors to be seen, or perhaps avoided.

Gregg Wonderly

===========================================================================
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/