couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Newson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1902) Success (201) response from Couchdb and document not created
Date Wed, 02 Oct 2013 20:49:42 GMT

    [ 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)

Mime
View raw message