Hi Willy,

On Thu, Mar 10, 2011 at 07:29:11AM +0100, Willy Tarreau wrote:
> Hi Simon,
> 
> On Thu, Mar 10, 2011 at 01:32:42PM +0900, Simon Horman wrote:
> > Hi,
> > 
> > this patch series attempts to allow haproxy to be restarted - perhaps
> > reconfigured would be a better term - without refusing or dropping
> > connections.
> 
> Wow, I'm impressed, you managed to do that really quickly !

Thanks. Its taken quite a bit of effort to get this far.

> You sent that at the right moment, because I have almost settled down
> on the internal changes needed to work on server-side keep-alive, so
> I should issue -dev4 once I'm fine with those changes. Then we'll be
> able to start by integrating your changes.

Great.

> In the mean time, I have a few questions which come to mind :
>   - does the socket cache consider all of the "bind" parameters ?
>     (eg: mss, interface, transparent, ...)

Yes, it attempts to take them into account, though in a very naive way.
If they all match then the socket cache entry can be re-used.
Otherwise the entry is invalidated.

Thanks for earlier advice on this else I would have probably
written code that didn't take these parameters into account at all.

>   - what happens if the new config file uses some conflicting bind
>     entries ? Eg: old config used to listen on 192.168.1.1:80 and
>     the new one uses 0.0.0.0:80 ? Or even :80 for the old one (IPv4)
>     and :::80 for the new one (IPv6) ?

I think there will be a problem. Lets talk about what would be a sensible
thing to do.

>   - does the master send a signal to all children asking them to unbind
>     (as we did with -sf) ?

Yes. It sends them a SIGUSR1.

It does not send them a SIGTTOU. Because although that works fine
I am not entirely sure how to sanely unwind the master at that point.

>   - do the debug modes (-d/-db) disable the master_worker mode ?

No. I can make that so if you like.

> In fact I'm interested in any corner cases we should be aware of so
> that we can clearly document them and indicate how to handle them
> (eg: fall back to -st if it's not possible to rebind, etc...)

I don't know of any off hand. But one of my reasons for posting
the code was to get more eyes on it so we can find such cases.

Re-initialising the configuration was somewhat non-trivial, and I am
sure that I have missed a few things.

> Thanks !
> Willy
> 
> 

Reply via email to