incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Johnson <ejohnso...@gmail.com>
Subject Re: 409 document conflict... but rev is correct
Date Wed, 04 Aug 2010 15:53:32 GMT
Hi Chris,

Thanks for the reply. It's not proprietary data in the file, however
before I ship out the file anywhere I'll have to check w/ some higher ups.

But there's a new twist on this now... like I mentioned in the previous
email, there is an hourly cron job updating about 80-90% of the records
in the database.  The error I'm writing about continued occurring for
about 6 more hours after my initial email last night but has seemed to stop.
Now the weird thing is this, the rev that was returned yesterday was
rev 2-xxx.  However a GET on the same document now returns rev 1005-xxxx,
but the db rev limit is 1000.

First, how can a document revision be higher than the rev limit of the database?
Second, if the document is updated at most once/hour, how does the revision
number jump from 2 to 1005 in less than 12 updates?

It just seems like some weird corruption issue.

 >> DB info >>

$ curl  http://user:password@127.0.0.1:5984/stream
{"db_name":"stream","doc_count":3171,"doc_del_count":4708,"update_seq":4254313,"purge_seq":0,"compact_running":false,"disk_size":209870954,"instance_start_time":"1280931315011866","disk_format_version":5}

 >> DB rev limit >>

$ curl  http://user:password@127.0.0.1:5984/stream/_revs_limit
1000

 >> Document w/ rev 1005-xxx >>

$ curl  http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
{"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"1005-f02accd95cc3dab487a7674083c8a3dd","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif

Keita - Mama"}

Thanks

Erick

On 8/4/10 10:30 AM, J Chris Anderson wrote:
>
> On Aug 3, 2010, at 9:57 PM, Erick Johnson wrote:
>
>> Hi all,
>>
>> I have an automated job that runs hourly updating the documents in a single
>> couch database.  The job has been running perfectly fine for about 2 months now.
>> However today, on updating one of the documents, couch consistently returns a 409
>> to the PUT.  When doing a GET on the document I see that the _rev value sent
>> in the PUT is the most up to date revision.
>>
>>  From the book and the wiki I know of no other conditions in which a 409 is returned.
>>
>> Could anyone offer me some advice on what else could be going on here?
>> Under what other conditions other than mismatched rev's does a 409 get returned?
>>
>
> This seems odd. If you can make it reproducible, it may be a bug. If you can't make it
reproducible, it could be a strange bug.
>
> Please don't compact or delete this database file. Is it possible to share the file with
me? If it is non proprietary data we'd be happy to take a look at the file itself to make
sure there aren't underlying issues.
>
> If you are comfortable doing so, please email me at jchris@apache.org and I'll arrange
a way to receive the .couch file so we can debug over here.
>
> Thanks,
> Chris
>
>> I appreciate any help.
>>
>> Thank you,
>>
>> Erick Johnson
>>
>> couchdb version:
>>
>> $ /usr/local/couchdb/bin/couchdb -V
>> couchdb - Apache CouchDB 0.11.0
>>
>> curl output:
>>
>>>>> the GET>>>
>>
>> $ curl -vvv http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
>> * About to connect() to 127.0.0.1 port 5984
>> *   Trying 127.0.0.1... connected
>> * Connected to 127.0.0.1 (127.0.0.1) port 5984
>> * Server auth using Basic with user 'user'
>>> GET /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
>>> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
>>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b
zlib/1.2.3 libidn/0.6.5
>>> Host: 127.0.0.1:5984
>>> Accept: */*
>>>
>> <  HTTP/1.1 200 OK
>> <  Server: CouchDB/0.11.0 (Erlang OTP/R13B)
>> <  Etag: "2-2a29a1819ff496ab1dc3d19f79f1c029"
>> <  Date: Wed, 04 Aug 2010 04:44:10 GMT
>> <  Content-Type: text/plain;charset=utf-8
>> <  Content-Length: 301
>> <  Cache-Control: must-revalidate
>> {"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama"}
>> * Connection #0 to host 127.0.0.1 left intact
>> * Closing connection #0
>>
>>>>> the PUT>>>
>>
>> $ curl -vvv -XPUT http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
-d '{"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}'
>> * About to connect() to 127.0.0.1 port 5984
>> *   Trying 127.0.0.1... connected
>> * Connected to 127.0.0.1 (127.0.0.1) port 5984
>> * Server auth using Basic with user 'user'
>>> PUT /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
>>> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
>>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b
zlib/1.2.3 libidn/0.6.5
>>> Host: 127.0.0.1:5984
>>> Accept: */*
>>> Content-Length: 255
>>> Content-Type: application/x-www-form-urlencoded
>>>
>>> {"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}HTTP/1.1 409 Conflict
>> <  Server: CouchDB/0.11.0 (Erlang OTP/R13B)
>> <  Date: Wed, 04 Aug 2010 04:44:15 GMT
>> <  Content-Type: text/plain;charset=utf-8
>> <  Content-Length: 58
>> <  Cache-Control: must-revalidate
>> {"error":"conflict","reason":"Document update conflict."}
>> * Connection #0 to host 127.0.0.1 left intact
>> * Closing connection #0
>>
>>
>> --
>> Erick Johnson
>>
>> 1-800-801-3381 x7006
>> Junction Networks
>> sip:erick@junctionnetworks.com
>> xmpp:erick@junctionnetworks.com
>

Mime
View raw message