> On Sep 5, 2023, at 8:49 PM, Sudheer Vinukonda
> <sudheervinuko...@yahoo.com.INVALID> wrote:
>
> That said, seems like a similar use case could be, if we ever wanted to
> persist an origin server error rate or down status etc or anything that’s
> dynamic similar to the administratively disabling h2 support status.
Right, for parents, you can mark them up / down via persistent librecords
metrics (as mentioned earlier). But this is really not awesome, because
librecords metrics really want to be mostly write(), and rarely read(). Reading
values at runtime (from the global metrics set) requires locking and overall
aren’t efficient. The new metrics are better at this, but they are not
persistent across restart (so not suitable for these use cases).
This is why we should have a generic persistent key-value store for state. But
feels like this can be done with existing libraries, and not rolling our own
for several use cases. Possibly we could use our HTTP cache for this, but let’s
figure that out as part of the design. My goal with this proposal was to simply
eliminate one of these custom persistent storages, to make work on HostDB
easier going forward.
Cheers,
— Leif
>
>> On Sep 5, 2023, at 7:45 PM, Sudheer Vinukonda <sudheervinuko...@yahoo.com>
>> wrote:
>>
>> Ugh sorry, should’ve read carefully - the use case seems more related to
>> turning on/off h2 at a individual server level (and not at an origin level)
>> and not a origin configuration which is unrelated.
>>
>> Sorry for the confusion!
>>
>>> On Sep 5, 2023, at 7:33 PM, Sudheer Vinukonda
>>> <sudheervinuko...@yahoo.com.invalid> wrote:
>>>
>>> Yeah, I meant the origin server session sharing configuration is a similar
>>> example to that of configuring an origin’s H2 support that was brought up,
>>> not that it’s related to HostDB.
>>>
>>>
>>>>> On Sep 5, 2023, at 7:12 PM, SUSAN HINRICHS <shinr...@ieee.org.invalid>
>>>>> wrote:
>>>>
>>>> I am also ok with removing the hostdb persistence.
>>>>
>>>> I am confused about how this is similar to origin server session sharing.
>>>>
>>>> On Tue, Sep 5, 2023, 6:12 PM Sudheer Vinukonda
>>>> <sudheervinuko...@yahoo.com.invalid> wrote:
>>>>
>>>>>>> I think this is similar to the the current and existing ugliness we
>>>>> have around marking parents down as well (which uses librecords and
>>>>> persistent metrics to store string values). That’s not great either, so a
>>>>> general concept of a persistent key-value store is needed already! I think
>>>>> your use case falls inline with what we need to do for the parent host
>>>>> up/down state as well, so even more reasons why we need that :).
>>>>> +1
>>>>> Another similar example that comes to mind is the Origin Server Session
>>>>> sharing configurations.
>>>>> Thanks,
>>>>> Sudheer
>>>>> On Tuesday, September 5, 2023 at 03:06:32 PM PDT, Leif Hedstrom <
>>>>> zw...@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>>> On Sep 5, 2023, at 3:59 PM, Masakazu Kitajo <mas...@apache.org> wrote:
>>>>>>>
>>>>>>> Sounds reasonable.
>>>>>>>
>>>>>>> Just one question. What would be the best places to store information
>>>>> like
>>>>>> "This origin server supports / prefers / breaks H2" ? We might want to
>>>>>> administratively disable H2-to-Origin for a particular origin server. We
>>>>>> currently don't use HostDB for it but I'm not sure where we can store it
>>>>> if
>>>>>> the persistence is going to be removed.
>>>>>
>>>>>
>>>>> This is a good question, and I think this is similar to the the current
>>>>> and existing ugliness we have around marking parents down as well (which
>>>>> uses librecords and persistent metrics to store string values). That’s not
>>>>> great either, so a general concept of a persistent key-value store is
>>>>> needed already! I think your use case falls inline with what we need to do
>>>>> for the parent host up/down state as well, so even more reasons why we
>>>>> need
>>>>> that :).
>>>>>
>>>>> Cheers,
>>>>>
>>>>> — Leif
>>>>>
>>>>>
>
