couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ayende Rahien" <aye...@ayende.com>
Subject Re: near view state server success
Date Sat, 08 Nov 2008 18:53:02 GMT
Getting a stale snapshot of the view should be very easy.Until you commit
the transaction, you can just get the current node.

On Sat, Nov 8, 2008 at 5:53 PM, Chris Anderson <jchris@apache.org> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message