You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Robert Newson (JIRA)" <ji...@apache.org> on 2013/10/02 22:49:42 UTC

[jira] [Commented] (COUCHDB-1902) Success (201) response from Couchdb and document not created

    [ https://issues.apache.org/jira/browse/COUCHDB-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13784412#comment-13784412 ] 

Robert Newson commented on COUCHDB-1902:
----------------------------------------

This might be delayed_commits (which defaults to true, unfortunately). We should document this much more prominently that delayed_commits must be disabled for production use.

curl -X PUT host:port/_config/couchdb/delayed_commits -d '"false"'

A future release will fix them by default (as part of the bigcouch merge).

When delayed_commits is set to true, a timer fires once per second to fsync pending writes to disk. A crash after a write but before this fsync would appear as you've described. 

The reason for this default is performance (at the cost of a small window of data safety) and also because benchmarks by those not aware of this setting (but oddly still confident to publish their findings) would, under some artificial workload, seem much poorer than other databases. It's past time we fixed this, imo.

The other possibility, which seems unlikely from your output, is that your write did indeed succeed and flush to disk but was the losing revision in a document with conflicts. Fetch the doc with ?meta=true to see if the _rev you thought you wrote is present.



> Success (201) response from Couchdb and document not created
> ------------------------------------------------------------
>
>                 Key: COUCHDB-1902
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1902
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>            Reporter: Atif Rasheed
>
> We are using Tangerine for early grade assessments which basically is a couchapp. One of our field engr reported that he was doing assessments and he had saved almost 9 results when all of a sudden tablet went off (probably due to batter issue). He powered it up again and after login to Tangerine he realized that all those saved results are gone. 
> We took logs and database from Tablet to PC for further analysis. We realized that it's actually true as we can see those attempts in couch.log and we can also see successful HTTP PUT requests as well on same _id's. Now we took that data from couch.log and tried to push it manually (using Restful client) to couchdb; and it worked. Now we are not sure what went wrong when tangerine pushed it to couchdb. Steps we followed and relevant outputs are pasted below for your reference. Will appreciate if someone help us out here.
> 0) Stage 0:
> We looked into couch.logs and found a successful PUT against a particular assessment result which is not available or visible in tangerine application.
> https://f.cloud.github.com/assets/4159723/1237563/744dfd8e-29da-11e3-8338-75c5478a96df.png
> 1) Stage 1:
> Tried to get the same document by id and the couchapp return not_found
> https://f.cloud.github.com/assets/4159723/1237571/9eb12650-29da-11e3-8570-f1f8f22ab4a9.png
> 2) Stage 2:
> Then we manually copied last revision from that log file And posted/pushed manually via REST Client to tangerine db (couchdb) and it was successful.
> https://f.cloud.github.com/assets/4159723/1237590/f3429e9c-29da-11e3-832b-05eab3688bca.PNG
> https://f.cloud.github.com/assets/4159723/1237592/f819b2de-29da-11e3-81a8-953f46da7dee.PNG
> Please note that the "_rev" at this stage is 34 because we hard-coded it in data file while sending through REST API. Obviously, if we remove that line from JSON, The _rev would be 1.



--
This message was sent by Atlassian JIRA
(v6.1#6144)