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
