Re: Those pesky blocking takes (was Re: outrigger "I/O error reading from mux connection")

Hi John,

So, I can remember a discussion a while back about relating to
contents() I think where we talked about streaming and the like.

It's late at night and I'm tired but on a slightly different angle:

Wondering if maybe some kind of callback mechanism might be interesting.

Let's say the client does:

take(Acceptor anAcceptor, Entry aTemplate, ....);

Where Acceptor is something like:

public interface Acceptor {
        public void offer(Entry aMatch) throws RemoteException;
}

So the client is lodging a take and saying, if you find a match, send it
to my Acceptor.  The Acceptor could be implemented as a remote callback
to the client.  The take would only succeed if the Entry were
successfully delivered to the client, i.e.  a RemoteException or
whatever would cause the take to be aborted in the server.

I hope that's reasonably intelligible....

Some issues:

(1)     Callbacks have similar properties potentially to registering a
listener via notify - wondering about firewalls etc.

(2)     I've spec'd the Acceptor takes an Entry which means the Entry would
be unpacked in the server which is something us JavaSpace implementors
have tended to run away from.  So there's some work to do there but it
ain't a show stopper.

(3)     I'm wondering if such a take should be leased by the client which
would allow the space to deduce that it's not even worth trying to send
a take to the client if the lease has expired.

(4)     I recall that Outrigger used to do this internally anyways and it
was dropped for amongst other things firewalls????  In this case, we'd
be building an explicit API for which we could spell out issues such as
firewalls and so on.  I can also imagine in a similar style to
EventMailbox allowing a client to have it's callbacks handled by some
intermediary which it could then poll - possibly pointless - not sure.

Okay, so I pointed the loaded gun at my foot, someone else needs to pull
the trigger :)

Dan.


John W. F. Mcclain wrote:
> 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/
>

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