[jira] [Created] (COUCHDB-2941) Stray insertions of _deleted_conflicts on regular doc CRUD

["Jan Lehnardt (JIRA)" <ji...@apache.org>]

Jan Lehnardt created COUCHDB-2941:
-------------------------------------

             Summary: Stray insertions of _deleted_conflicts on regular doc CRUD
                 Key: COUCHDB-2941
                 URL: https://issues.apache.org/jira/browse/COUCHDB-2941
             Project: CouchDB
          Issue Type: Bug
          Components: Database Core
            Reporter: Jan Lehnardt


When using a high number of GET/PUT/DELETE requests on the same doc id, CouchDB will eventually introduce _deleted_conflicts. Since this happens silently and is as of yet undocumented (to my knowledge), users don’t account for this. The result, with thousands of _deleted_conflicts in a doc, operations to that doc can take up many seconds up to minutes.

This ticket is to find out out the root cause and what we can do to avoid this issue, or protect users better in another way.

I pasted a code snipped below that demonstrates the issue into a gist: https://gist.github.com/janl/638d8aa39841df829cd8. It is written in C#. To run this on Unixy systems, install mono (`brew install mono` / `apt-get install mono-complete`) and compile the file with `mcs Program.cs` and then run it with `mono Program.exe`.

On my machine with CouchDB 1.6.1 first conflicts show up between 100 and 1000 doc revisions. The Program stops once it finds the first _deleted_conflict. If you comment that part of the code, it will continue to add a _deleted_conflict per 100-1000 revisions, eventually making CouchDB operations on that doc very slow.

In addition, here is a CouchDB log leading up to the first _deleted_conflict: https://gist.github.com/janl/368f60df74f867dd4698

You will notice that the code is not using a CouchDB best-practice (high delete/update rates to a single doc), but for the particular use case, there is no simple way around it. Either way though, CouchDB should not suddenly be slow.

Of course, users should handle conflicts, but the test program shows that the _deleted_conflicts appear during regular document CRUD, and no replication or _bulk_docs with new_edits are involved and that has taken the user that reported this to me, and myself, by surprise.

As I understand CouchDB document update (write/delete) semantics, I’d expect no _deleted_conflicts to show up ever. The fact that it only shows rarely even with a huge update frequency shows that this is clearly some deeply hidden edge-case.







--
This message was sent by Atlassian JIRA
(v6.3.4#6332)