Subject: CAP: Bounded latency

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 14:33:08 -0400

CAP has features to let the client specify that the server should not 
spend more than X amount of time on a request. I believe that these 
features should be removed, or made optional, because they are 
essentially impossible to implement in a single-threaded server. If my 
server is working on the client's request, the only way I could possibly 
apply the latency limit would be by setting an alarm to interrupt me. 
But such alarms are not safe; generally speaking, they can interrupt any 
operation, whether or not it leaves the system in an unsafe state.

If the bounded latency stuff is cut, that means ABORT and CONTINUE must 
be cut.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"HTTP is what happens in the absence of good |
[email-masked] <mailto:[email-masked]>|design." -- Keith Moore                      |
\==============================================================/

---

From: George Babics <[email-masked]>
Date: Sun, 19 Aug 2001 14:07:29 -0400

Another way to implement it would be for the thread to
check every X seconds or milliseconds if the latency
time has run out or not. This may slow the thread down a
little, it will not be completely accurate, and will not
be the nicest thing to code. The latency time will only be
an approximation.

  Are there potentially other problems for a single-threaded server?
Are bounded latency, and the ABORT and CONTINUE commands the
only ones?

  Should we make these features optional? Remove them?
Are there some reasons why they are a must? Opinions?

  BTW, the CAP requirements draft does mention these
features:

    "Support functionality such that the client is not forced to remain
    connected and waiting while a command is in progress. One possible
way
    for the protocol to meet this requirement would be to allow the CU
to
    abort a command that is taking too long."

  (The CAP requirements draft has expired. We should repost it.)

George

---

From: John Stracke <[email-masked]>
Date: Mon, 20 Aug 2001 10:41:53 -0400

George Babics wrote:

>time has run out or not.
That won't work, though.  If I have a single-threaded system, relying on 
blocking function calls (e.g., for database access), then I can't check 
the clock during those calls.

>Are there potentially other problems for a single-threaded server?
Not that I've noticed.

>    abort a command that is taking too long."
I'm not sure, but I believe making the bounded-latency features optional 
would meet this requirement.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Never mind the GUIs--Unix won't be for the   |
[email-masked]|masses until we fix backspace & delete.      |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Tue, 21 Aug 2001 20:15:09 -0500

> operation, whether or not it leaves the system in an unsafe state.

This is not strictly true.  A single-threaded server can take a break
between parts of a large operation and see if there is something else
requiring its attention, at safe intervals.

> If the bounded latency stuff is cut, that means ABORT and CONTINUE must

how about downgrading them to MAY status.  A client could always just
drop the connection and let the server pick up the pieces.

-- 
                                           David Nicol 816.235.1187
"... raised indoors and tested by certified technicians"

---

From: John Stracke <[email-masked]>
Date: Wed, 22 Aug 2001 10:10:52 -0400

David L. Nicol wrote:

>>essentially impossible to implement in a single-threaded server.
>>
>
False.  A server is typically implemented with some sort of backend 
store (say a database); the API to this database is quite likely to be 
blocking.  In such a case, it would be impossible to take a break during 
the database access--and the database access is probably the largest 
chunk of time to service a CAP request.

-- 
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |A computer without Windows is like a chocolate|
[email-masked]|cake without mustard.                         |
\===============================================================/