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 <j...@jagunet.com> 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 <ylavic....@gmail.com> wrote: >> >> On Mon, Feb 5, 2018 at 8:09 PM, Jim Jagielski <j...@jagunet.com> wrote: >>> >>> On Feb 5, 2018, at 7:38 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> >>> 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. >
