With my proposal, this is lost only if IP:port(s) or ServerName/Alias(s) change, which is already a win and shouldn't change the way each balancer is bound to its vhost (i.e. a request on a vhost wouldn't be accounted/handled by a lb on another vhost).
On Tue, Feb 6, 2018 at 3:18 PM, Yann Ylavic <[email protected]> wrote: > It depends on what you do now, but if it's "reload the server with any > change before the vhost" than there is an issue. > You'd lose SHMs, persisted files, all the vhost's balancers states... > > On Tue, Feb 6, 2018 at 2:29 PM, Jim Jagielski <[email protected]> wrote: >> IMO, unless there are issues/problems with what we do *now*, >> we shouldn't be changing things... >> >>> On Feb 6, 2018, at 2:24 AM, Yann Ylavic <[email protected]> wrote: >>> >>> On Mon, Feb 5, 2018 at 8:09 PM, Jim Jagielski <[email protected]> wrote: >>>> >>>> On Feb 5, 2018, at 7:38 AM, Stefan Eissing <[email protected]> >>>> wrote: >>>> >>>> 2. Does httpd core expose a VirtualHost Identifier in its API and >>>> what would the semantic properties of such an identifier be? >>>> >>>> Yes, it does. It's the server_rec. That contains all the info required >>>> to determine any and all fashion of "unique" Vhost IDs. >>> >>> So, for balancers (slotmems) needs, how about: >>> - All IP:port from server_addr_rec list + >>> - ServerName + >>> - ServerAlias(es) >>> (i.e. hash/MD5 thereof). >>> ? >>> >>> The rationale is that this is solely what determines the "election" of >>> a server_rec for each request. >>> All duplicates, since nothing is enforced on this in httpd (should >>> it?), would never be elected at runtime (i.e. ignored). >>> We may want to detect the case though, or do we blindly reuse slotmems >>> for them (w/o any consistency checks)? >>> >>> >>> Regards, >>> Yann. >>
