> Am 06.02.2018 um 16:14 schrieb Jim Jagielski <[email protected]>:
> 
> I don't think it does. 

I do not understand. I feel that I am missing something here.

You're saying that the scenario does not exist or that it does not trigger the 
described effect?

>> On Feb 6, 2018, at 9:18 AM, 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.
>>> 
> 

Reply via email to