Those pesky blocking takes (was 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

[...]

>
>
> Yep, I think you nailed it.

People seem to run into this quite a bit. We have seen this
a couple of times on the list, I have seen it couple more times
privately (including one just a couple of weeks ago). Hopefully
this will be a lesson for all of you designing services APIs w/
non-idempotent operations, but that still leaves the question
of what can be done for spaces. It does seem to be causing
people problems, worse it is usually non-obvious if you have not
see it before (and sometimes even then....) and I would like
to make it better if I can.

As I wrote in the message linked to above I generally believe fixing
it in the implementation of take is a bad idea (as it is potently
expensive, not a complete solution, and likely to give people
a false sense of security) though I would be interested to know
if people agree with that analysis.

I could imagine various extensions to space:

  o New APIs for take that would not be (as?) venerable
  to the problem

  o Extension to spaces that would allow for more transactional
  interactions w/o using Transactions

  o A low cost transaction model that would make using a
  Transaction for a single take less costly and/or easier

Seems like there must be options around documentation and
maybe error reporting that might also be useful. Anyway,
if anyone has an idea how to make this issue less of a problem
or more obvious, I would be curious to hear them.

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