compared with
Current by Mark Nunberg
on Dec 23, 2012 15:04.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (4)

View Page History
Given that Couchbase Server may be run anywhere from a small VM on old, slow disks to running on physical hardware and thus persistence and replication can vary from below 10ms to potentially 100s of milliseconds, clients SHOULD have an adaptive algorithm that uses statistics advertised by the response from OBSERVE to guide how it polls to check for the given state.

The recommendation is for the client to initially poll once after 5 milliseconds, and then poll with increasing frequency until the average persistence/replication time is reached. Do note that the value will be 0 if the server has no information on average persistence or replication time [(note: as of this writing, the stats are there for persistence time]).

Alternatively, the client library MAY implement a simple loop of polling. The recommendation is that this loop is done on a 100ms interval for up to 400 iterations or 40 seconds. If the client library implements this approach, it MUST allow these values to be tuned.
The client build a request packet once and put there all keys it interested in. After that it sends to all servers owning vbuckets (master and replicas). The servers should send back response with only keys he knows about.

[ 12/23/2012 ]:
This seems outdated. For keys the server doesn't know about, the entire response would be
invalidated by a NOT_MY_VBUCKET error.

See https://github.com/membase/ep-engine/blob/2.0.0/src/ep_engine.cc#L3486



h1. Implementation Questions
{quote}