Re: Outrigger and blitz -- lingering take?

Here is GigaSpaces "take" on this behavior. :-)

From the early days of GigaSpaces the take operation checks if the client
really exists before actually removing the entry from the space.

If the client does not exist the entry will not be removed from the space.

There is a way to disable this behavior to allow the space to act as other
JavaSpace implementations. This in-fact will improve a bit the take
operation performance, but may lead to inconsistent behavior.

Please note the space browser will increment the take operation statistics
(based on the space BEFORE_TAKE) event in such scenario - but the actual
take operation will not happen and the entry will not be removed from the
space when matching entry will be written into the space. You may view the
Class instance count and view the entry themselves to verify this.



The notification mechanism includes similar capability that removes notify
registrations when dead client identified. GigaSpaces 5.2 include enhanced
capability that identifies slow notifications consumers and removes their
notify registration based on the speed they are "pulling" their notification
from the space. See:

http://www.gigaspaces.com/wiki/display/GS/Slow+Consumer



Shay





-----Original Message-----
From: John McClain - Sun Microsystems, Inc. [mailto:[email protected]]
Sent: Friday, January 19, 2007 10:40 AM
To: [email protected]
Subject: Re: Outrigger and blitz -- lingering take?



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


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