Subject: Re: CAP TODO: single threaded

From: "John Stracke" <[email-masked]>
Date: Thu, 15 Nov 2001 16:11:15 -0500

John Stracke wrote:

>> Can anybody explain to me whom bounded latency is supposed to benefit? 
It
>> wastes CS resources to cancel a request that's taken too long; it
>> complicates the protocol for implementors;
>
>assuming a forking server in Perl that performs actions
>by making virtual atomic alterations to a file system, here's
>how to make it crap out if there's no response in 90 seconds.

I'm afraid "crap out" is an excellent term for what will happen.  That 
"atomic" is the hard part.

Even if you're using an API that guarantees atomicity, consider what 
happens if the modification succeeds, and then the alarm goes off before 
you can cancel it.

/=============================================================\
|John Stracke                   |Principal Engineer           |
[email-masked]  |Incentive Systems, Inc.      |
|http://www.incentivesystems.com|My opinions are my own.      |
|=============================================================|
|For an engineer, paranoia is not an affliction; it's a tool. |
\=============================================================/

---

From: Doug Royer <[email-masked]>
Date: Thu, 15 Nov 2001 15:14:39 -0700

> happens if the modification succeeds, and then the alarm goes off before

This issue is not unique to CAP.

If the alarm (server times out?), then the server would send
a reply that said so. If the next command is a CANCEL, then
it is canceled. You ether cancel it before it is done, or not.
If the reply to the CANCEL is 'no command in progress' - then
it was not canceled as it finished before you canceled it.

If you cancel (ABORT) it before it is done, the CS replies
to the cancel with 'yep - canceled it'.

Is there another state?

-Doug