hosting.config requires restart, but docs say reloadable

[mlibbey]

Docs say that hosting.config changes are reloadable:
https://docs.trafficserver.apache.org/en/8.0.x/admin-guide/files/hosting.config.en.html
"After you modify hosting.config, navigate to the Traffic Server bin directory and run traffic_ctl config reload to apply your changes."
This line has been in the docs since the initial release.

In testing, we observe that changes to hosting.config only take effect after restart. The best way I've found to see this:

• make a host with 2 volumes. In hosting.config have
  hostname=* volume=1
• after starting up, fetch objects. traffic_ctl metric match volume | grep bytes_used should show proxy.process.cache.volume_1.bytes_used increasing.
• edit hosting.config, adding the origin (for example hostname=origin.example.org volume=2
• reload trafficserver
• fetch more objects. You'd expect proxy.process.cache.volume_2.bytes_used to now increase, however, volume_1 continues to increase instead.
• Upon restart and more fetches, proxy.process.cache.volume_2.bytes_used begins increasing.

Our primary use case for the hosting.config is to assign "properties" that either have low max-age or useful lifetime (for instance a live sports stat object may be constantly updated; a live video segment is only fetched in a small time window). Being able to dynamically add such use cases would be useful.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.

[ezelkow1]

Ill take a look when I get a chance, I ran into this as well not too long ago. Hopefully its actually reloadable and was just missed on the list of files

[bneradt]

@ezelkow1 volunteered to take a look at this.

[ezelkow1]

just started getting back to this. So I can see that as of now (maybe after my tweaks, I cant remember now) that the hosting.config will reload. However the issue is with the hosttable/matchers associated with the caches when they go to do a host lookup for the volume, those are not being updated across reloads, so requests still land on their old host->vol matchings

So still playing with that

[ezelkow1]

Do have this narrowed down now. I believe its because when it went to load a new table in it was doing ink_atomic_swap(new_table, ptr_to_cache_table_in_use). ink_atomic_swap, does not in fact swap, it just assigns ptr=var in (ptr,var). So it was just copying the old table on top of the newly calculated one, and then proceeding, never updating the actual hosting table in use.

Ive experimented with a few options and have it working, just still discussing the best route