How does stale query work?

Couchbase Server
1

Hello,

Sorry, I know the documentation is very clear about how stale=ok should work. But, I am not seeing the right behavior.

I am running a _count reduce query with stale set to OK.

Query query = new Query();

query.setKey(key);
query.setIncludeDocs(true);
query.setReduce(true);
query.setStale(Stale.OK);

I add a new document that changes the _count. I wait for about 10 seconds and then run the above query. I expect that automatic index to have run by now and should retrieve the latest count. But, I get back the old count. If the run the query again, I get the latest updated count. So, the system is behaving more like Stale.UPDATE_AFTER.

I have checked the auto index setting by running:

curl http://admin:password@localhost:8091/settings/viewUpdateDaemon

I get back:

{“updateInterval”:5000,“updateMinChanges”:5000,“replicaUpdateMinChanges”:5000}

Am I misunderstanding the way stale queries work? Thank you.

2

If stale=ok is set, Couchbase will not refresh the view even if it is stale. The benefit of this is a an improved query latency. If stale=update_after is set, Couchbase will update the view after the stale result is returned. If stale=false is set, Couchbase will refresh the view and return you most updated results.

Hope this helps!

3

You are just repeating what’s in the documentation, which I understand. But, I am seeing a different behavior. That is why I posted my question.

4

What is your version of Couchbase Server? Java Client?

Is it possible to provide us with some sample output screenshots on what you are seeing?

Thanks,

5

can you make sure you are running on full cluster or production mode?

6

5000ms is not enough, Couchbase also checks 5000 changes(“updateMinChanges”:5000) to re-index.
See: http://docs.couchbase.com/couchbase-manual-2.2/#automated-index-updates

7

Note that as of 3.0, the semantics of stale=false have changed slightly. It now means whatever is current in the active location for the vbuckets, which is closer to user intent and is actually faster in 3.0 than it was in 2.0.

It also means you no longer need to wait for persistence before querying a view.

See the 3.0 release notes for details.