You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Tim Tisdall <ti...@gmail.com> on 2012/06/01 17:09:30 UTC
local.ini settings not taking precedence
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.
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
-Tim
Re: local.ini settings not taking precedence
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 1 June 2012 22:56, Tim Tisdall <ti...@gmail.com> wrote:
> I have the same config order as you.
Phew.
> It seems to have written the log level change to local.ini . However, I'm
> not sure how to interpret that... does that mean it's giving local.ini the
> highest precedence?
Yes.
> So, I looked at http://localhost:5984/_utils/config.html and it's now
> reporting
> socket_options [{nodelay, true}]
>
> This is after I changed local.ini to have the value
> socket_option = [{keepalive, true}, {nodelay, true}]
>
> since both default and local.ini say keepalive is true, it seems odd that
> it's now dropped...
It looks as if local & default inis would merge the proplists, but
it's treated as a simple text replacement when read in local.ini.
Despite fiddling, the only thing I can think of is that maybe you
you've got your sections mis-matched. Can you check this with
curl & confirm?
dave@akai couchdb % curl $COUCH/_config/httpd/socket_options
"[{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}]"
NB editing the files directly will require restarting couchdb, using
the HTTP API does not.
A+
Dave
Re: local.ini settings not taking precedence
Posted by Tim Tisdall <ti...@gmail.com>.
I have the same config order as you.
It seems to have written the log level change to local.ini . However, I'm
not sure how to interpret that... does that mean it's giving local.ini the
highest precedence?
So, I looked at http://localhost:5984/_utils/config.html and it's now
reporting
socket_options [{nodelay, true}]
This is after I changed local.ini to have the value
socket_option = [{keepalive, true}, {nodelay, true}]
since both default and local.ini say keepalive is true, it seems odd that
it's now dropped...
On Fri, Jun 1, 2012 at 2:15 PM, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 1 June 2012 17:09, Tim Tisdall <ti...@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
>
Re: local.ini settings not taking precedence
Posted by Dave Cottlehuber <da...@muse.net.nz>.
On 1 June 2012 17:09, Tim Tisdall <ti...@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