Hello,
On Fri, 26 Oct 2018 at 17:41, William Lallemand <wlallem...@haproxy.com> wrote: > Hi Aleks, > > With a nbproc setup, the first goal is to be able to access multiple stats > sockets from one socket. > > In a more "modern" nbthread setup, it's possible to have only one worker, but > we still fork a new process upon a reload. > The problem is that at the moment it's not possible to connect to the stats > socket of a process which is leaving. Sometimes it's really useful to debug > and > see the session which are still connected on the old process. And that's the > ultimate goal of this feature (not covered yet, but soon :-) ) > > It also implements a "show proc" which lists the PIDs of the processes. > > Regards, Btw could stdout logging leverage some of this infrastructure? I assume that if the master process would write to stdout (synchronously), we would not stall our workers because of slow log readers? https://www.mail-archive.com/haproxy@formilux.org/msg17436.html https://github.com/dockerfile/haproxy/issues/3 https://github.com/docker-library/haproxy/pull/39 It looks like in the docker world, everything other than stdout logging is unacceptable - at least for official docker image, and I'm wondering if the master/worker process model along with this infrastructure could theoretically help there, without sacrificing the performance of the event loop or log reliability. Regards, lukas
