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