incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bosko Milekic" <bosko.mile...@gmail.com>
Subject Re: couchdb test suite failing randomly?
Date Wed, 23 Jul 2008 04:56:55 GMT
On Mon, Jul 14, 2008 at 4:04 PM, Bosko Milekic <bosko.milekic@gmail.com> wrote:
> On Mon, Jul 14, 2008 at 2:38 PM, Paul Carey <paul.p.carey@gmail.com> wrote:
>> You could, perhaps, confirm Jan's hypothesis by visiting about:config in
>> Firefox, setting network.http.max-connections-per-server to one and
>> verifying that the tests no longer fail.
>>
>> Paul
>
> You're right, that gets rid of the errors.  So it is the concurrency
> issue Jan expected.

So I'm trying to determine the conditions under which the concurrency
issue manifests itself.

In one scenario where I'm able to periodically trigger failures on the
recreate_doc test within Firefox with my current machine load, with
network.http.max-connections-per-server set to 30 and Firebug Net
event logging enabled (it's deff timing sensitive), I get the test
fail with:

# Exception raised: {"error":"conflict","reason":"Update conflict"}

The recreate_doc test looks like this:

function (debug) {
    var db = new CouchDB("test_suite_db");
    db.deleteDb();
    db.createDb();
    if (debug) {
        debugger;
    }
    var doc = {_id: "foo", a: "bar", b: 42};
    T(db.save(doc).ok);
    T(db.deleteDoc(doc).ok);
    for (var i = 0; i < 10; i++) {
        doc = {_id: "foo"};
        T(db.save(doc).ok);
        doc = db.open("foo");
        doc.a = "baz";
        try {
            T(db.save(doc).ok);
        } finally {
            T(db.deleteDoc(doc).rev != undefined);
        }
    }
}

Here is what Firebug tells me is happening when the test fails:

DELETE test_suite_db -> 200 OK

PUT test_suite_db -> 201 Created

PUT foo -> 201 Created

DELETE foo?rev=1488096128 -> 200 OK

PUT foo -> 201 Created

PUT foo -> 412 Precondition Failed. Response is nothing too special I
don't think:
{"error":"EXIT","reason":"{function_clause,[{cjson,tokenize,\n
                [undefined,{decoder,utf8,null,1,1,any}]},\n
 {cjson,decode1,2},\n                  {cjson,json_decode,2},\n
          {couch_httpd,handle_doc_request,5},\n
 {couch_httpd,handle_request,2},\n
{mochiweb_http,headers,4},\n                  {proc_lib,init_p,5}]}"}

DELETE foo?rev=2057594976 -> 412 Precondition Failed. Response is:
{"error":"conflict","reason":"Update conflict"}


What's interesting is the series of Firebug Net events when the test
*passes* (e.g., when I toggle the
network.http.max-connections-per-server firefox about:config setting
back to 15 and Firebug Net is enabled, I can fairly reliably get the
test to pass).  The sequence of events looks more like this:

DELETE test_suite_db -> 200 OK

PUT test_suite_db -> 201 Created

PUT foo -> 201 Created

DELETE foo?rev=1488096128 -> 200 OK

PUT foo -> 201 Created

GET foo -> 200 OK

PUT foo -> 201 Created

DELETE foo?rev=1364649865


Notice the GET foo, which corresponds to the db.open("foo"), and which
is absent from the scenario where the test fails.  I'm not sure if
this is because the GET http request gets broken and therefore Firebug
never manages to display it in the Net console, or if it's because the
GET is never happening.  Assuming no ajax-related bug in jQuery, it's
the former.  So the GET http connection ends up in some sort of hung
state while the subsequent PUT starts to get processed?

So if this is some sort of bug in mochiweb, has anyone been able to
determine the conditions under which it occurs?  I'm trying to
determine if my current anticipated use of couchdb would be affected
by this bug.

Cheers,
-- 
Bosko Milekic <bosko.milekic@gmail.com>
http://www.tumbl.es/

Mime
View raw message