couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Misterious 409 conflicts: Duplicated PUT requests
Date Sat, 26 May 2012 13:58:45 GMT
Hi,

Not related for java client, but I could recall bug for python one:
http://code.google.com/p/couchdb-python/issues/detail?id=200
However, I've failed to reproduce it nor face it.

> I think the problem has been, that I did not close all responses...
>
> The Apache client throws an exception when I am reusing a connection
> that has open responses... That helped a lot to fix it.

For couchdb-python there is same connection reusage. I wounder how
they could leave opened in his case, but I'll try to dig in this way.
Thanks for a case!

--
,,,^..^,,,


On Sat, May 26, 2012 at 5:34 PM, Johannes Schneider
<mailings@cedarsoft.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I did use the default client.
> But now I have switched to the Apache Client.
>
> I think the problem has been, that I did not close all responses...
>
> The Apache client throws an exception when I am reusing a connection
> that has open responses... That helped a lot to fix it.
>
> On 26.05.2012 15:21, Robert Newson wrote:
>> Jersey can use either the JDK's http client or Apache HttpClient,
>> which are you using?
>>
>> I know that the Apache HttpClient will resubmit requests under
>> some conditions (and you can disable it).
>>
>> http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e281
>>
>>  The default retry handler assumes PUT is idempotent but this is
>> not true for CouchDB. For it to be true, we would have to send an
>> identical response to the 2nd attempt as we did to the first,
>> which, as you can see, we don't.
>>
>> CouchDB is behaving correctly, your client is the problem.
>>
>> Sent from my iPhone
>>
>> On 26 May 2012, at 12:34, Johannes Schneider
>> <mailings@cedarsoft.com> wrote:
>>
>> Hi guys,
>>
>>
>> I have a big problem here. Very often my unit tests fail. I have
>> asked about this problem some time ago - but couldn't find that
>> thread anymore...
>>
>> I have upgrade couchdb to 1.2.0 and run Wireshark to locate the
>> problem.
>>
>>
>> Ok. I am uploading my design documents before each unit tests.
>> Sometimes (about 1 in 100) I get an 409 from couchdb.
>>
>> The problem is, that there are two PUTs instead of just one. Of
>> course the second one fails with a 409.
>>
>> But my client is *not* aware that it is sending the request twice.
>>
>>
>> Here is the relevant part of the couchdb.log:
>>
>>
>> [Sat, 26 May 2012 09:52:59 GMT] [info] [<0.23835.0>] 127.0.0.1 - -
>> GET /collustra_test$attachments/_design/rating 404 [Sat, 26 May
>> 2012 09:52:59 GMT] [debug] [<0.23835.0>] httpd 404 error response:
>> {"error":"not_found","reason":"missing"}
>>
>> [Sat, 26 May 2012 09:52:59 GMT] [debug] [<0.23813.0>] 'PUT'
>> /collustra_test$attachments/_design/rating {1,1} from "127.0.0.1"
>> Headers: [{'Accept',"text/html, image/gif, image/jpeg, *; q=.2,
>> */*; q=.2"}, {'Connection',"keep-alive"},
>> {'Content-Length',"4910"}, {'Content-Type',"text/plain"},
>> {'Host',"localhost:5984"}, {"Millis","1338025979060"},
>> {'User-Agent',"Java/1.6.0_26"}] [Sat, 26 May 2012 09:52:59 GMT]
>> [debug] [<0.23813.0>] OAuth Params: [] [Sat, 26 May 2012 09:52:59
>> GMT] [debug] [<0.23836.0>] 'PUT'
>> /collustra_test$attachments/_design/rating {1,1} from "127.0.0.1"
>> Headers: [{'Accept',"text/html, image/gif, image/jpeg, *; q=.2,
>> */*; q=.2"}, {'Connection',"keep-alive"},
>> {'Content-Length',"4910"}, {'Content-Type',"text/plain"},
>> {'Host',"localhost:5984"}, {"Millis","1338025979060"},
>> {'User-Agent',"Java/1.6.0_26"}] [Sat, 26 May 2012 09:52:59 GMT]
>> [debug] [<0.23836.0>] OAuth Params: [] [Sat, 26 May 2012 09:52:59
>> GMT] [info] [<0.23813.0>] 127.0.0.1 - - PUT
>> /collustra_test$attachments/_design/rating 201 [Sat, 26 May 2012
>> 09:52:59 GMT] [debug] [<0.23836.0>] Minor error in HTTP request:
>> conflict [Sat, 26 May 2012 09:52:59 GMT] [debug] [<0.23836.0>]
>> Stacktrace: [{couch_db,update_doc,4, [{file,
>>
>> "/tmp/a/build-couchdb/dependencies/couchdb/src/couchdb/couch_db.erl"},
>>
>>
> {line,429}]},
>> {couch_httpd_db,update_doc,6, [{file,
>>
>> "/tmp/a/build-couchdb/dependencies/couchdb/src/couchdb/couch_httpd_db.erl"},
>>
>>
> {line,931}]},
>> {couch_httpd_db,do_db_req,2, [{file,
>>
>> "/tmp/a/build-couchdb/dependencies/couchdb/src/couchdb/couch_httpd_db.erl"},
>>
>>
> {line,230}]},
>> {couch_httpd,handle_request_int,5, [{file,
>>
>> "/tmp/a/build-couchdb/dependencies/couchdb/src/couchdb/couch_httpd.erl"},
>>
>>
> {line,317}]},
>> {mochiweb_http,headers,5, [{file,
>>
>> "/tmp/a/build-couchdb/dependencies/couchdb/src/mochiweb/mochiweb_http.erl"},
>>
>>
> {line,136}]},
>> {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,227}]}]
>> [Sat, 26 May 2012 09:52:59 GMT] [info] [<0.23836.0>] 127.0.0.1 - -
>> PUT /collustra_test$attachments/_design/rating 409 [Sat, 26 May
>> 2012 09:52:59 GMT] [debug] [<0.23836.0>] httpd 409 error response:
>> {"error":"conflict","reason":"Document update conflict."}
>>
>> [Sat, 26 May 2012 09:52:59 GMT] [debug] [<0.23837.0>] 'GET'
>> /collustra_test$attachments {1,1} from "127.0.0.1" Headers:
>> [{'Accept',"text/html, image/gif, image/jpeg, *; q=.2, */*;
>> q=.2"}, {'Connection',"keep-alive"}, {'Host',"localhost:5984"},
>> {'User-Agent',"Java/1.6.0_26"}]
>>
>>
>> Now that seems to be very obvious... But: On the client side I see
>> just *1* PUT. I am using Jersey Client API (Java).
>>
>> Wiresharks shows that there are - in fact - two PUT. But there is
>> *no* response on the first PUT. Instead there are several TCP
>> errors (RST, ACK).
>>
>> http://pastebin.com/17jV8MnA
>>
>>
>> So I have:
>>
>> Client (Jersey): PUT Wireshark: PUT, Errors but no response, PUT,
>> response CouchdB: PUT, (No Response?), PUT, Response
>>
>>
>>
>> So I think the problem is, that the response to the first PUT is
>> lost somewhere - but executed successfully. And my client resends
>> the request and gets the 409...
>>
>> So my question is basically: Does anybody have an idea how/why the
>> response is lost?
>>
>>
>>
>> Thanks,
>>
>> Johannes
>>
>>
>
> - --
> Johannes Schneider - blog.cedarsoft.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJPwNvxAAoJEAytD9R7Qv6dPfIIANolSSnoEXi3/ZCJd2QfSfH+
> rDmuF0UDSsMasfxg0HFnbUxJnvumbrhPska52g2ijZ/srubBj9Ir66NPy5RV/yc1
> D8y8IMreA9dCXfhldVy80TOnfImFBN3RlHEFXkGygdW5ceUSMsl/1r6jZDfWstvE
> WIQnqck/kgPUlk6hQ2w4DrleAKkOiE1+TgbQud0vxcIHZwUUCHMgwX4QB+eCplfc
> GSTyHu6138kqK128SxjCqBKTZ45EY0y96jiUmdxD4P8nTet54Gf93QoPPwJtZCyd
> cZuvwYNBAvwTrtv5S4S1G/ZRwOFIsD/q579IqrOohVOa+UL/pTzrgFDdr3UCZMQ=
> =gH6g
> -----END PGP SIGNATURE-----

Mime
View raw message