On Mon, Jan 12, 2009 at 3:43 PM, John Bartak <[email protected]> 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:[email protected]] > Sent: Monday, January 12, 2009 11:19 AM > To: [email protected] > Subject: Re: Error when running two requests to same view simultaneously > > On Mon, Jan 12, 2009 at 2:10 PM, John Bartak <[email protected]> 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:[email protected]] >> Sent: Saturday, January 10, 2009 9:54 AM >> To: [email protected] >> Subject: Re: Error when running two requests to same view simultaneously >> >> On Sat, Jan 10, 2009 at 8:48 AM, Michael McDaniel <[email protected]> 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 >> >
