ChiragMoradiya opened a new issue #1342: View query doesn't consider latest 
write for db with 3 replicas
URL: https://github.com/apache/couchdb/issues/1342
 
 
   
   When I run Query, using Couchdb view, immediately after write operation, the 
result doesn't consider latest write. Instead previous revision of that 
document is used to generate result.
   
   Below is the details about my setup and steps to reproduce.
   
   ## Setup
   - CouchDB version: 2.1.1
   - Cluster: 3 Nodes
   - OS: Ubuntu 16.04
   - I've created  a database with 3 replicas.
   - There is around 1000 documents in the database.
     - Each document contains 2 fields: `name` and `balance`.
   - There is a view function named `by_name` is available.
     - `name` field is emitted as key.
   
   ## Steps to Reproduce
   - Following steps are performed  ~50 times
     - Read one of the document (random).
     - Increase it's balance by 1
     - Save the document in CouchDb
     - Read the same document using CouchDb view `by_name` with 
`include_docs=true`.
     - Validate whether it's `balance` is same as just updated.
   - I've observed that only after around 4-5 iterations, balance validation 
step fails. 
   - When I did check for revision of the document, I found that result 
provided me older revision of the document. (OR didn't provide latest revision).
   - This test I have performed differently using `reduce` function to get sum 
of `balance`. There also, query result was generated on previous revision of 
the document.
   
   ## Expected Behavior
   Query result should always consider latest revision of the document.
   
   ## Additional Observations
   **Works for database with 2 replicas**
   I've created another database with 2 replicas and  performed same test(s) on 
it.  In this case I didn't found any issue.
   
   ## Possible cause
   
   - To understand possible cause, let's understand my assumptions for how 
document write and query result generation works in CouchDB.
   
   ### How document write works
   
   - It work's based on value of 'w' configured for each database.
   - When it's value is 2, then a write is called successful only when the 
document is written on at least 2 nodes.
   
   ### How view query works
   - Query request is distributed to all the nodes having replica of that 
database.
   - Node which gives fastest result, is considered final result and delivered 
to user.
   - I have observed this by enabling detailed logging on all nodes of my 
cluster.
   
   Based on above 2 assumptions, I have following conclusion for the cause of 
this issue:
   
   - When a particular document is written, CouchDb has responded after writing 
document on 2 nodes. So, 1 node is not yet having latest revision of that 
document. Though, This node will synchronize eventually. But, assume that 
before that query arrived at the cluster.
   - So, query request is distributed to all 3 nodes of my cluster.
   - The node on which the document isn't yet written will respond faster than 
other 2 nodes as it doesn't require to rebuild the index as there isn't any 
changes in documents. While other 2 nodes on which document was written 
successfully, will take time to respond as they need to rebuild the index 
before generating query result.
   - And as per my assumption, fastest response is returned. And thus, latest 
revision of the document wasn't considered for query result generation.
   
   ### Why issue doesn't exist for databases with 2 replicas ?
   It's obvious. Though explaining here.
   
   For databases with 2 replicas, value of 'w' was 2. So, when I write document 
it's written to both of the replicas. So, query result is generated by either 
of these 2 nodes will consider latest write, always.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to