Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 15204 invoked from network); 12 Jan 2009 20:51:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Jan 2009 20:51:55 -0000 Received: (qmail 69454 invoked by uid 500); 12 Jan 2009 20:51:49 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 69419 invoked by uid 500); 12 Jan 2009 20:51:49 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 69406 invoked by uid 99); 12 Jan 2009 20:51:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jan 2009 12:51:49 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.198.227 as permitted sender) Received: from [209.85.198.227] (HELO rv-out-0506.google.com) (209.85.198.227) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jan 2009 20:51:40 +0000 Received: by rv-out-0506.google.com with SMTP id g37so10730035rvb.35 for ; Mon, 12 Jan 2009 12:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=JV/ygHbXbo/GFHCbYIeara5GngZLfL9zxC8tap/74Is=; b=Ivt1jCMS66aKG8TTx9LVlDjC0uzVGnBZSbb/j/8HyPT4Vi5o45pM2HyY3DePNupQH3 2At3QHT2u0ZLvLDFnrCsfOmezK5bE54KRq48yTqI8QQcuh+yUWVdeHiB1OpKeNCNjuwj B4X6pC3aYeTxU8ngofdk12/YtrDC1OQnBoN2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SzgD7/Ong2V5UhrULH+UGmBl+8jHKWhdtJrvXEHv784mMT9RQMl2oHnk2n8UgC6pJC eHFB8QxL2O1ax74Z2zBjmOMXQlhEdnWDCl3pO7oY6/KcELlVDZuEikU7TAUkvVaGu90h HPqGdiLv8IT5G/O89W8iWUTlDHagAo2USF6PE= Received: by 10.141.177.2 with SMTP id e2mr13883719rvp.53.1231793480501; Mon, 12 Jan 2009 12:51:20 -0800 (PST) Received: by 10.141.75.15 with HTTP; Mon, 12 Jan 2009 12:51:20 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 15:51:20 -0500 From: "Paul Davis" To: user@couchdb.apache.org Subject: Re: Error when running two requests to same view simultaneously In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090110164853.GI10545@delora.autosys.us> X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jan 12, 2009 at 3:43 PM, John Bartak wrote: > Adding the "X-Couch-Full-Commit" header seems to make it more likely to get 412's. But I'm still getting lots of cases where I don't see a 412. Hmm. I haven't at all looked at this new code, but inconsistent behavior is unexpected at best. Given my understanding of it works, I would expect all or none raise 412's. Would it be possible for you to boil this into a small test case that we can play with? Or maybe someone else can chime in with an explanation. I for one am totally lost. Paul Also, I don't see any documents in the database with a "_conflict" attribute on them. > > If I can't rely on getting 412's back if somebody else updated the revision of the document, I'll have to figure out some other trick to determine if the current thread updated the document. Perhaps updating an attribute on the document with a GUID that only the current thread knows about. > > -----Original Message----- > From: Paul Davis [mailto:paul.joseph.davis@gmail.com] > Sent: Monday, January 12, 2009 11:19 AM > To: user@couchdb.apache.org > Subject: Re: Error when running two requests to same view simultaneously > > On Mon, Jan 12, 2009 at 2:10 PM, John Bartak wrote: >> It appears that the latest code (0.9.0a733848) does fix the crash of the server. I now get back a result string that has an error value of missing instead of the document: >> >> {"total_rows":2,"offset":0,"rows":[ >> {"id":"09e2fb54e77545c0aec61578fe041965","key":["repository.repositoryfile","ownerid","filename"],"value":null,"error":"missing"}, >> {"id":"8cc55e26dfb047b09f222d7967f2a047","key":["repository.repositoryfile", "ownerid","filename"],"value":null,"doc":{"_id":"8cc55e26dfb047b09f222d7967f2a047","_rev":"2138313893","OwnerId":"ownerId","Name":"filename"}} >> ]} >> >> I'll have to update my code to handle that, but that's no big deal. >> >> Unfortunately, I don't get back 412's when two threads attempt to update the same revision of a document simultaneously. This happens for both the bulk_docs api and the standard PUT api: >> >> [info] [<0.3374.0>] 192.168.200.1 - - 'GET' /fileinttests_20090112_105825_501_1818439740/473dccb50cb54a57abe19e7687c491ce?rev=4134090793 200 >> [info] [<0.3371.0>] 192.168.200.1 - - 'GET' /fileinttests_20090112_105825_501_1818439740/473dccb50cb54a57abe19e7687c491ce?rev=4134090793 200 >> [info] [<0.3371.0>] 192.168.200.1 - - 'PUT' /fileinttests_20090112_105825_501_1818439740/473dccb50cb54a57abe19e7687c491ce 201 >> [info] [<0.3374.0>] 192.168.200.1 - - 'PUT' /fileinttests_20090112_105825_501_1818439740/473dccb50cb54a57abe19e7687c491ce 201 >> >> In the two threads that I have running, I first get the document I want to revise and I then update the revision. >> > > I have a sneaking suspicion that this is from the code that damien > commited a few days ago. Try adding a head like [1] to each of your > requests to check the status of each. Also, in your example, to double > check that this is expected behavior, you should look at that document > and verify it has a _conflict attribute. Remember that we're working > with eventual consistency here. This type of thing is expected and > it's your app's responsibility to figure things out. > > [1] X-Couch-Full-Commit: true > > HTH, > Paul Davis > >> >> >> -----Original Message----- >> From: Chris Anderson [mailto:jchris@gmail.com] >> Sent: Saturday, January 10, 2009 9:54 AM >> To: user@couchdb.apache.org >> Subject: Re: Error when running two requests to same view simultaneously >> >> On Sat, Jan 10, 2009 at 8:48 AM, Michael McDaniel wrote: >>> The short answer is that there is no function couch_doc:to_json_doc/2 >>> that accepts the arguments ( {not_found, missing}, [] ) gracefully >>> >>>> {function_clause, >>>> [{couch_doc,to_json_obj,[{not_found,missing},[]]}, >>>> ... >>> >> >> The problem seems to have been in the error handling in the >> include_docs code. Do you mind updating to the latest trunk and >> attempting to recreate the error? It should be fixed. >> >> >> -- >> Chris Anderson >> http://jchris.mfdz.com >> >