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

Lachlan O'Dea wrote:
> On 15/09/2005, at 0:30, John W. F. Mcclain wrote:
>
>
>>I think Gregg is probably right. Logging the
>>"writing EntryRep[com.ca.jini.space.hello.StdioHelloEntry] (txn =
>>null)"
>>message is pretty much the last thing the server side write
>>method does before returning the necessary info to create the lease
>>in the client. At this point the entry has
>>been made visible to other threads (and if this was a persistent space
>>made durable). Is the client doing the take doing a blocking
>>take? If yes my guess is that when the write happens there is a query
>>from a previous, but now dead, instance of the taking client still
>>in progress, that take gets the newly written entry, the entry
>>gets dumped on the floor (since the previous client is dead)
>>and JERI's java.io.EOFException occurs when JERI turns around
>>to get the next call from the dead taking client.
>>
>>See this post for a longer discussion of this issue:
>>
>>  http://archives.java.sun.com/cgi-bin/wa?A2=ind0405&L=javaspaces-
>>users&P=R2084&I=-3
>>
>>If you are not doing a blocking take or there was no previous
>>instance of the taking client, I need more info....
>>
>>Hope this helps, if not we can try again....
>
>
> Yep, I think you nailed it.

Well I think Gregg nailed it, I just added some background....

Anyway I am glad we were able to help you track down your problem.

> My receiver is doing a blocking take with
> Long.MAX_VALUE timeout. Because of the simplistic nature of my test
> code, I was just doing a ctrl-c when I needed to stop and restart the
> clients. A few more tests confirmed that the problem occurs only
> after I ctrl-c the taking process. It always seems obvious in hindsight.
>
> 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?

Transactions (w/ a capital T) is the std., most general way
to deal with this sort of problem, but there are other methods.
On one hand general is good because it is widely applicable and
usually involves less conceptual complexity, on the other hand
"general" often == "slower than you could archive if you were
willing to be less general".

There are other ways though. For example if the entry being taken
is some sort of task that will generate a result that will
ultimately be processed by the original submitter of the task, then
the submitter can keep track of which tasks have been fished and
which tasks have not, and at some point resubmit the tasks
who's results seem to have been lost (this assume that it
is ok if some tasks get run more than once).

As along as we are talking about distributed computing in general
one could imagine using a transactional protocol without using
Transactions. Transactions work here because they are introducing
an additional communication (which involves multiple round trips
and an intermediary) between the client and the space that allows
the client to confirm that it has processed the entry before the
space eliminates the entry entirely from the space. You could
imagine achieving a similar effect by using an ad-hoc protocol
(which might have fewer round trips) instead of using Transactions
(just to be clear this would be a bit tricky with spaces as
currently conceived, I am bring it up more as something to
think about when people design their own service interfaces -
though it also offers areas where we might want to extend spaces).

Another possibility is that you design your system so it is ok to
lose some entries (at some level having the client resubmit tasks
is an instance of this idea). It may be that the entry in question
is targeted for a particular client and if that client dies it is
ok to lose its entries, or the entry represents some state that
changes at a regular interval and any lost entry will soon be
replaced by a new entry with the new state. It could also be that the
entry just represents some transient state or some optimization
which is not required for correct operation.

> Thank you everyone for your responses. As a newbie to Javaspaces,
> it's certainly encouraging to receive such a level of assistance.
--
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/