On Thu, Jul 25, 2019 at 10:23:24AM +0200, Aleksandar Lazic wrote:
> Hi.
> 
> Am 25.07.2019 um 10:06 schrieb William Lallemand:
> > On Thu, Jul 25, 2019 at 08:07:45AM +0200, Baptiste wrote:
> >> Hi Daniel,
> >>
> >> You're making a good point. Use the file system was the simplest and
> >> fastest way to go when we first designed this feature 4 or 5 years ago.
> >> I do agree that now with master/worker and threaded model being pushed that
> >> using the runtime-api may make sense and would be even more "cloud native".
> >>
> >> Maybe @William would have an advice on this one.
> >>
> >> Baptiste
> > 
> > Hi,
> > 
> > The simplest way to do that with the current architecture would be to do the
> > same thing as the "seamless reload" feature (-x).
> > 
> > The new process will need to connect to the old one, send the `show servers
> > state` command, and then parse it using the server state file parser.
> > 
> > However, what I don't like with this, is that we still need to configure a
> > "stats socket" manually in the configuration, it is not doable yet using the
> > internal socketpair of the master-worker model.
> 
> How about to catch the idea from Daniel to use a *internal* peers setup for 
> such
> states?
> 

I don't think it makes sense to use peers for that.

The idea to do it with the stats socket is good, we only need to improve the
master-worker so a worker could use the socketpair to connect to another
worker. The only drawback is that it needs a configured stats socket in the
current model, but we already have this limitation with the seamless reload.

-- 
William Lallemand

Reply via email to