Re: Outrigger and blitz -- lingering take?

"John McClain - Sun Microsystems, Inc." <[email protected]> Fri, 19 Jan 2007 10:40:17 -0500
Newsgroups gmane.comp.java.sun.javaspaces
Message-ID <[email protected]>
Expanding on Dan and Greg's spot on messages....

Dan Creswell wrote:
> Hi Patrick,
>
> Greg T has basically hit the nail on the head.
>
> When your client lodges a take with the space and blocks, a take request
> is put on a "noticeboard" within the space that someone is looking for a
> certain kind of entry.
>
> If the client dies, although the connection will eventually be ripped
> down (hopefully) the space impl won't necessarily hear of this.  Thus
> the request is still on the "noticeboard".
>
> Now, when a matching write comes along the "noticeboard" is checked, a
> match found and an attempt is made to return it to the client which is
> no longer present.  This failure tends to happen silently and thus the
> space can't be smart enough to reinsert the taken entry for you.

And even if RMI/Java/OS/network stack told the space that the client had
failed, it still wouldn't cover the case where the client failed after
it had gotten the entry, but before it had processed it, so there would
still be a window where from the application's perspective the entry
could be lost.

Dan's Option 2 (and generally the techniques alluded to in 3 as well)
allow the cases where the client fails after the take returns but before
the entry is processed to be covered too.

> In the
> meantime, the "noticeboard" is now clear and normal behaviour resumes.
>
> Several things to note:
>
> (1)     If the newly written entry turns up after the expiry time for the
> blocking take (assuming you didn't do Lease.FOREVER), the above won't
> happen.
>
> (2)     You can ensure this never happens by having clients wrap operations
> in explicit Transactions.  Transactions are leased and can thus be
> automatically aborted in face of client failure.  And when the
> transaction is aborted, the space will be compelled to "reverse" the
> fault take and put the newly written entry back into the available entry
> population.
>
> (3)     There are other ways to handle this issue using concepts from
> various of the network protocols out there like re-posting entry's after
> a period due to no ack from a client (which has died) etc.
>
> Hope that helps,
>
> Dan.
>
> Logan, Patrick wrote:
>> I am seeing what apears to be some sort of "lingering take" on a
>> javaspace. This happens in Outrigger as well as Blitz.
>>
>> What I am observing… a worker process is blocked on a take with a null
>> transaction. I kill the process.
>>
>> Using the Blitz dashboard I can see after the kill, 1 blocked take. (I'm
>> not up on similar tools for Outrigger but all the other observations are
>> the same when I use that.)
>>
>> Then I start another process running the same worker, and after doing
>> some other spaces stuff, it soon blocks on a take using the same template.
>>
>> When another process writes an entry that matches that template, it
>> appears this "lingering taker" gets the entry.
>>
>> I am not sure what the explanation is for this "lingering take". Running
>> ps indicates the process is really gone.
>>
>> When I run this with a non-null transaction everything seems fine. I
>> have no trouble using transactions to make sure cleanup happens, but I
>> am a little surprise that the null transaction case with both space
>> implementations do not get cleaned up when a process blocked on a take
>> gets killed.
>>

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

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

         - David Brooks

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