Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of
 Viktor.Szabo@morganstanley.com designates 205.228.53.68 as permitted sender)
From: "Szabo, Viktor (Enterprise Infrastructure)"
	<Viktor.Szabo@morganstanley.com>
To: <user@couchdb.apache.org>
Subject: RE: possible compact bug in 1.1.1
Thread-Topic: possible compact bug in 1.1.1
thread-index: AcypA5vr6+QWsbbdRX6tO3a1wVdWHQAFvAWAAABjz4AAAfkHAAAAWVag
Date: Tue, 22 Nov 2011 14:45:58 +0000
Message-ID: <9032450E6B3D8244858652FFFD6E29BC029675@OZWEX0202N2.msad.ms.com>
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
References: 
 <9032450E6B3D8244858652FFFD6E29BC0294FC@OZWEX0202N2.msad.ms.com><7321244256499370376@unknownmsgid><9032450E6B3D8244858652FFFD6E29BC029611@OZWEX0202N2.msad.ms.com>
 <CAMWZAjm5R=DraukTKb0-mARnXpQphKo5Zdn8OX=C5sgvDeHE6g@mail.gmail.com>
In-Reply-To: 
 <CAMWZAjm5R=DraukTKb0-mARnXpQphKo5Zdn8OX=C5sgvDeHE6g@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I'm getting an {"error":"conflict","reason":"Document update conflict."} =
message all the time.

-----Original Message-----
From: Marcello Nuccio [mailto:marcello.nuccio@gmail.com]=20
Sent: 22 November 2011 15:36
To: user@couchdb.apache.org
Subject: Re: possible compact bug in 1.1.1

What happens if you change the document?
For example if you insert a field with a timestamp as in:

$ curl -X PUT -H "Content-type: application/json"
http://hostname:7002/test/dummy -d '{ "_id": "dummy", "a": "'$(date
+%s)'" }'

Marcello

2011/11/22 Szabo, Viktor (Enterprise Infrastructure)
<Viktor.Szabo@morganstanley.com>:
> The very same thing happens:
>
> $ curl -X POST -H "Content-type: application/json"=20
> http://hostname:7002/test/_compact
> {"ok":true}
> $ curl -X PUT -H "Content-type: application/json" =
http://hostname:7002/test/dummy -d '{ "_id": "dummy" }'
> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"}
>
> By the way, I've been using the API doc found over here:
> http://www.couchbase.org/sites/default/files/uploads/all/documentation
> /couchbase-api-dbdoc.html#couchbase-api-dbdoc_db_post
>
> Shouldn't I?
>
> Thanks,
> Viktor
>
> -----Original Message-----
> From: Robert Newson [mailto:robert.newson@gmail.com]
> Sent: 22 November 2011 14:28
> To: user@couchdb.apache.org
> Subject: Re: possible compact bug in 1.1.1
>
> When couch requires a Referer header it is expecting form-data not =
json. So it could be you have found a bug there. I'd call it serious if =
you can induce the same thing with the correct input format.
>
> Use PUT instead of POST, drop the referer header and let us know what =
happens.
>
> Sent from my iPhone
>
> On 22 Nov 2011, at 10:44, "Szabo, Viktor (Enterprise Infrastructure)"
> <Viktor.Szabo@morganstanley.com> wrote:
>
>> Hi CouchDB users,
>>
>> I don't know if this is a known issue or not, but I've been=20
>> experiencing strange behaviour in version 1.1.1 after initiating=20
>> compaction. Even though there's already a doc with the _id value of=20
>> "dummy" in my database, if I want to have it re-inserted after a =
compact operation is started, 9 times out of 10, I receive an "ok":true =
notification. Occasionally I'm seeing the expected conflict error.
>>
>> $ curl -X POST -H "Content-type: application/json"
>> http://hostname:7002/test/_compact
>> {"ok":true}
>> $ curl -X POST -H "Content-type: application/json" -H "Referer: =
http://hostname:7002/" http://hostname:7002/test -d '{ "_id": "dummy" }'
>> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"}
>> $ curl -X POST -H "Content-type: application/json"
>> http://hostname:7002/test/_compact
>> {"ok":true}
>> $ curl -X POST -H "Content-type: application/json" -H "Referer: =
http://hostname:7002/" http://hostname:7002/test -d '{ "_id": "dummy" }'
>> {"ok":true,"id":"dummy","rev":"1-967a00dff5e02add41819138abb3284d"}
>> How is this possible?
>>
>> Given that I sometimes get an "ok" confirmation, but sometimes get a=20
>> "conflict error" for the very same request sent to the database with =
the very same content, I don't really feel secure about the integrity of =
the service.
>> I'm thinking that the issue is related to the fact that the database=20
>> already had accepted a doc with the same id and content, but still, =
undeterministic behaviour is not something I like.
>>
>> Do you have a clue on what might be going on?
>>
>> (I wasn't able to reproduce under 1.1.0. Used a single-node instance=20
>> with no replication set up and no clients connecting to the service)
>>
>> Thanks,
>> Viktor
>>
>> ---------------------------------------------------------------------
>> -
>> ----
>> NOTICE: Morgan Stanley is not acting as a municipal advisor and the =
opinions or views contained herein are not intended to be, and do not =
constitute, advice within the meaning of Section 975 of the Dodd-Frank =
Wall Street Reform and Consumer Protection Act. If you have received =
this communication in error, please destroy all electronic and paper =
copies and notify the sender immediately. Mistransmission is not =
intended to waive confidentiality or privilege. Morgan Stanley reserves =
the right, to the extent permitted under applicable law, to monitor =
electronic communications. This message is subject to terms available at =
the following link: http://www.morganstanley.com/disclaimers. If you =
cannot access these links, please notify us by reply message and we will =
send the contents to you. By messaging with Morgan Stanley you consent =
to the foregoing.
>
> ----------------------------------------------------------------------
> ----
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the =
opinions or views contained herein are not intended to be, and do not =
constitute, advice within the meaning of Section 975 of the Dodd-Frank =
Wall Street Reform and Consumer Protection Act. If you have received =
this communication in error, please destroy all electronic and paper =
copies and notify the sender immediately. Mistransmission is not =
intended to waive confidentiality or privilege. Morgan Stanley reserves =
the right, to the extent permitted under applicable law, to monitor =
electronic communications. This message is subject to terms available at =
the following link: http://www.morganstanley.com/disclaimers. If you =
cannot access these links, please notify us by reply message and we will =
send the contents to you. By messaging with Morgan Stanley you consent =
to the foregoing.

-------------------------------------------------------------------------=
-
NOTICE: Morgan Stanley is not acting as a municipal advisor and the =
opinions or views contained herein are not intended to be, and do not =
constitute, advice within the meaning of Section 975 of the Dodd-Frank =
Wall Street Reform and Consumer Protection Act. If you have received =
this communication in error, please destroy all electronic and paper =
copies and notify the sender immediately. Mistransmission is not =
intended to waive confidentiality or privilege. Morgan Stanley reserves =
the right, to the extent permitted under applicable law, to monitor =
electronic communications. This message is subject to terms available at =
the following link: http://www.morganstanley.com/disclaimers. If you =
cannot access these links, please notify us by reply message and we will =
send the contents to you. By messaging with Morgan Stanley you consent =
to the foregoing.