incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <d...@muse.net.nz>
Subject Re: local.ini settings not taking precedence
Date Fri, 01 Jun 2012 18:15:02 GMT
On 1 June 2012 17:09, Tim Tisdall <tisdall@gmail.com> wrote:
> Maybe I'm missing something simple, but my understanding is that local.ini
> values should take precedence over values in default.ini .  However, I'm
> trying to set nodelay to true for the socket_options and that doesn't
> appear to be working.


Strictly speaking the ini file that's last in the chain takes precedence, and
its also the file that gets changes written to.

You can see which ones are being used and in what order with

$ couchdb -c
/usr/local/etc/couchdb/default.ini
/usr/local/etc/couchdb/local.ini

> Here's what's in default.ini :
> socket_options = [{keepalive, true}, {nodelay, false}]
>
> here's what's in local.ini:
> socket_options = [{nodelay, true}]
>
> http://localhost:5984/_utils/config.html is reporting that socket_options
> is equal to:
> [{keepalive, true}, {nodelay, false}]
>
>
> I've restarted the couchdb server multiple times since making the change,
> but just noticed now that the change doesn't appear to have been made.  I'm
> using v1.2.0

A restart is not required, the erlang magic picks up the changed config for you.

If your config chain above doesn't raise warning bells, can you temporarily
up the log level to debug, try this:

    COUCH=http://admin:passwd@localhost:5984
    curl -vXPUT $COUCH/_config/httpd/fake_key -d '"fake_value"'

You should see something like this in your logs:

[Fri, 01 Jun 2012 18:10:23 GMT] [debug] [<0.287.0>] 'PUT'
/_config/httpd/fake_key {1,1} from "127.0.0.1"
Headers: [{'Accept',"*/*"},
          {'Authorization',"Basic YWRtaW46cFGSzc3dk"},
          {'Content-Length',"12"},
          {'Content-Type',"application/x-www-form-urlencoded"},
          {'Host',"localhost:5984"},
          {'User-Agent',"curl/7.21.4 (universal-apple-darwin11.0)
libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5"}]
[Fri, 01 Jun 2012 18:10:23 GMT] [debug] [<0.287.0>] OAuth Params: []
[Fri, 01 Jun 2012 18:10:23 GMT] [info] [<0.287.0>] 127.0.0.1 - - PUT
/_config/httpd/fake_key 200

And you should be able to grep for fake_key if needed to see where
it's being written to.

In fact you can even use upping the log level as a check:

    curl -vXPUT $COUCH/_config/log/level -d '"debug"'

and back to error

    curl -vXPUT $COUCH/_config/log/level -d '"error"'

A+
Dave

Mime
View raw message