Bug #55598 for Perlbal: perlbal.conf order matters more than expected

Mon Mar 15 12:03:21 2010 ANDK [...] cpan.org - Ticket created

Subject:

perlbal.conf order matters more than expected

Thanks to the helpful dumpconfig command I could discover that some of my my config settings in my perlbal.conf file were being ignored. This works: create service pb1 set role = reverse_proxy set idle_timeout = 120 A grep on idle_timeout shows me: SET idle_timeout = 120 BUT this doesn't work: create service pb1 set idle_timeout = 120 set role = reverse_proxy A grep on idle_timeout with this config doesn't yield anything because idle_timeout has been set back to the default (30) when the line 'set role' was reached. I'm not trying to provide a fix, I hope the fix is obvious for you. Let me know if you would prefer a patch. Thanks,

Sat Mar 20 01:16:03 2010 hachi [...] cpan.org - Correspondence added

I'm gonna punt on this till we get this release out, I see several ways to fix it... and I also want to see if there are similar issues with SET plugins = as well. On Mon Mar 15 12:03:21 2010, ANDK wrote: Show quoted text

> Thanks to the helpful dumpconfig command I could discover that some of > my my config settings in my perlbal.conf file were being ignored. > > This works: > > create service pb1 > set role = reverse_proxy > set idle_timeout = 120 > > A grep on idle_timeout shows me: > > SET idle_timeout = 120 > > BUT this doesn't work: > > create service pb1 > set idle_timeout = 120 > set role = reverse_proxy > > A grep on idle_timeout with this config doesn't yield anything because > idle_timeout has been set back to the default (30) when the line 'set > role' was reached. > > I'm not trying to provide a fix, I hope the fix is obvious for you. Let > me know if you would prefer a patch. > > Thanks,

Sat Mar 20 01:16:07 2010 The RT System itself - Status changed from 'new' to 'open'

Fri Jul 13 06:36:29 2012 SREZIC [...] cpan.org - Correspondence added

I also stumbled over this problem and can provide some diagnostics. Perlbal::Service::init() is called as soon the role of a service is set. In init() all tunables are checked and the default (if this tunable is applicable for the current role) is applied. This means that all settings which are done before "set role = ..." and have a default value are lost. I am not sure how to best fix this, but maybe the configuration parser should do two passes. In the first pass just the "set role = ..." line is searched and applied (which would call init()), and in the 2nd pass all the other configuration lines should be handled (but not "set role"). Regards, Slaven