couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@gmail.com>
Subject Re: First admin user is not created in _users db
Date Mon, 22 Feb 2010 15:53:07 GMT

On Feb 22, 2010, at 8:06 AM, Matt Goodall wrote:

> On 22 February 2010 12:06, Matt Goodall <matt.goodall@gmail.com> wrote:
> On 22 February 2010 11:43, Matt Goodall <matt.goodall@gmail.com> wrote:
> On 22 February 2010 11:28, Matt Goodall <matt.goodall@gmail.com> wrote:
> On 22 February 2010 10:53, Brian Candler <B.Candler@pobox.com> 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.
> 
> Yep, Futon's createAdmin is calling doLogin and doSignup in sequence, both of which are
async. doSignup can only happen once doLogin has completed successfully.
> 
> Attached is a patch (git diff against 0.11.x branch) that chains the two calls. Works
consistently and correctly for me now. Hope it looks ok, feel free to reformat as necessary.

> 
> Sorry Noah, but I think getting this fix in is a showstopper for the 0.11 release.
> 

Matt,

Thanks for the investigation and patch. It's pretty much always worked for me over here, so
I didn't realize it was an issue. 

I've committed (and am backporting) the patch. I think this is trivial enough that it doesn't
need to go through Jira, but I've added you to the thanks file.

Chris

> - Matt
>  
> 
> 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
> 
> 
> <futon-createAdmin-race.diff>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message