From dev-return-8761-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Feb 22 12:07:11 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 44161 invoked from network); 22 Feb 2010 12:07:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Feb 2010 12:07:10 -0000 Received: (qmail 8721 invoked by uid 500); 22 Feb 2010 12:07:10 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 8629 invoked by uid 500); 22 Feb 2010 12:07:10 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 8619 invoked by uid 99); 22 Feb 2010 12:07:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Feb 2010 12:07:09 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of matt.goodall@gmail.com designates 74.125.82.52 as permitted sender) Received: from [74.125.82.52] (HELO mail-ww0-f52.google.com) (74.125.82.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Feb 2010 12:07:03 +0000 Received: by wwi18 with SMTP id 18so388053wwi.11 for ; Mon, 22 Feb 2010 04:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5m//zS766SXSGNPW7chl9QDaw3NNuK9s5GRh+CyG/XE=; b=V/zM6Z7AZjxPDnrSLEq1KvXJM22kTv9Dl6I71P9Q28S4io6CI16GhKkVVUVz+Vf/kI 362Q1ctWPCMSdYeaPJLkD9YbGdxJFqK0dwdhGa9oIOxDKqaIqx3SwxbDqgHGmzofCBUy RKMGoxkOkXindEPZttLSCBS6xmPk5DEPgbXp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=HrMiVr+xFRLRjtSNO6IkVeq0FH9w4uhFo9eWEbkDWo/WW5bZwxeNvhz5hdfEH6Cqh3 RF2Mkfsh4wAxb/+eHvK3U/6KDLe6JzG4c8EZ2QRboNpsd5wpF68752S076Eeecr3VSgz IZcGTxhdROj1XKtyptpzrVhos5lWwqONPucdg= MIME-Version: 1.0 Received: by 10.216.86.3 with SMTP id v3mr281604wee.190.1266840401331; Mon, 22 Feb 2010 04:06:41 -0800 (PST) In-Reply-To: <214c385b1002220343l26dd5676g6710303b021058c8@mail.gmail.com> References: <214c385b1002220032sc441e45t9c759cc7bca8ddda@mail.gmail.com> <20100222105332.GB5364@uk.tiscali.com> <214c385b1002220328x27a43febl38fac2aa51f3fde0@mail.gmail.com> <214c385b1002220343l26dd5676g6710303b021058c8@mail.gmail.com> Date: Mon, 22 Feb 2010 12:06:41 +0000 Message-ID: <214c385b1002220406l742c0973rdab14a877f24890@mail.gmail.com> Subject: Re: First admin user is not created in _users db From: Matt Goodall To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e6d784191bc89d04802f445d --0016e6d784191bc89d04802f445d Content-Type: text/plain; charset=UTF-8 On 22 February 2010 11:43, Matt Goodall wrote: > On 22 February 2010 11:28, Matt Goodall wrote: > >> On 22 February 2010 10:53, Brian Candler wrote: >> >>> On Mon, Feb 22, 2010 at 08:32:50AM +0000, Matt Goodall wrote: >>> > Before 0.11 gets released ... after creating the first admin user in a >>> > completely fresh install of the 0.11.x branch I see a _users database >>> > containing only design doc, i.e. no doc for the new user. Subsequent >>> admin >>> > users do get added the the _users db. >>> >>> Is the first admin user created in local.ini then? >>> >>> I thought *all* admin users ended up created in local.ini. At least, when >>> I >>> created two admins via futon, I got them both in local.ini. But I haven't >>> tested this for a week or so. >>> >> >> The first admin user added to in local.ini but not in the _users database. >> >> Subsequent admin users are added to local.ini and the _users database. >> > > OK, I seem to be getting different behaviour on different machines. Let me > look into it more first, perhaps I didn't install something correctly > (although I tried multiple times and just did the same on a new machine). > Looks like a timing problem. Gut feeling says the slower machine the more likely it is to occur but that's entirely speculative. So, when it work I see the following in the couchdb log: [info] [<0.101.0>] 127.0.0.1 - - 'PUT' /_config/admins/matt 200 [info] [<0.100.0>] 127.0.0.1 - - 'GET' /_session 200 [info] [<0.101.0>] 127.0.0.1 - - 'POST' /_session 200 [info] [<0.101.0>] 127.0.0.1 - - 'GET' /_session 200 [info] [<0.100.0>] 127.0.0.1 - - 'PUT' /_users/org.couchdb.user%3Amatt 201 And when it fails I see: [info] [<0.105.0>] 127.0.0.1 - - 'PUT' /_config/admins/matt 200 [info] [<0.95.0>] 127.0.0.1 - - 'GET' /_session 200 [info] [<0.95.0>] 127.0.0.1 - - 'PUT' /_users/org.couchdb.user%3Amatt 409 [info] [<0.105.0>] 127.0.0.1 - - 'POST' /_session 200 [info] [<0.105.0>] 127.0.0.1 - - 'GET' /_session 200 Both of those were run on the same machine with a completely fresh couchdb install (deleted between runs) and a newly opened chromium "incognito" window to avoid browser caching between sessions. It looks like there's two concurrent async requests and it just depends on which one completes first ... but I haven't looked at the JS code to prove that. Just for extra information, on a faster machine I've not seen it fail yet and on a slower machine I've not seen it succeed. Like I said, that's a speculative conclusion based on the playing I've done here. - Matt --0016e6d784191bc89d04802f445d--