Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.217.15 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=thXXdzBcUGplyK8GNYF0YZMRRTgWq6LDOJ0vjoP8jhrLk+/dOxrlpbyU2bOb5dnRAu
         nyCtniOEi+EbbDBUMk/cPI89HWY5Ve+rmJSgAqW6tEAcGXoqYTgAz4lIoU2/M9wbnaOX
         Z7cT0OlWIcW+ne09wUZGjxv92vcgHU6jUZRSw=
Message-ID: <e282921e0811080753o3bccde13o91cb32e55aa5e315@mail.gmail.com>
Date: Sat, 8 Nov 2008 07:53:40 -0800
From: "Chris Anderson" <jchris@apache.org>
Sender: jchris@gmail.com
To: couchdb-dev@incubator.apache.org
Subject: Re: near view state server success
In-Reply-To: <27d8d0930811072306u77c5ddffu921349f6799936f2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45E2AC4D-B362-41F8-9E28-63B25D362E6E@apache.org>
	 <EB8FE341-C75C-4B2C-9C6A-69678EADCF52@apache.org>
	 <e282921e0811072236m18ceace2ye685ca8099591a93@mail.gmail.com>
	 <e2111bbb0811072252h4a9a14e9m524936a1558ee230@mail.gmail.com>
	 <27d8d0930811072306u77c5ddffu921349f6799936f2@mail.gmail.com>

On Fri, Nov 7, 2008 at 11:06 PM, Ayende Rahien <ayende@ayende.com> wrote:
> I want to be able to get a response in a limited amount of time.Even if that
> response is optionally stale (marked by a header?)
>

This would be ideal. The hard part here is getting access to a stale
view representation from disk. I'm not sure you can get  a btree root
from the disk, that is known to be consistent, unless it just came
from the updater process. Maybe it'd be simple enough to do... but in
any case, it's not really the feature that this patch is working on,
although the patch does lay the groundwork for these more complex view
query modes.

Damien maybe you can chime in about getting consistent but stale view
indexes from the disk?

> The absolute worse thing to happen is to have a request just wait for 5
> minutes before timing out or returning a result.
> That ties up resources across the entire network

Once again, I think it really is the site operator's responsibility to
keep any user-facing views up to a certain degree of readiness. In
some cases, a quick error may be better than waiting 5 seconds (or 5
minutes) for a view to generate. But in other cases, we'd send the
error instead of generating the view, and then turn out to have the
view generate in less than a second. There's no way to know ahead of
time how long it will take to update a view. Luckily, keeping your
views up to date makes all these problems go away.

Chris


-- 
Chris Anderson
http://jchris.mfdz.com