HybridCache : implement the tag expiration feature

[mgravell]

Implement tag expiration in HybridCache

The HybridCache system has a "tags" feature; rather than building a bespoke per-backend secondary index (like how the redis OutputCache backend works), here we move everything into the core library:

• in the DefaultHybridCache, we maintain a map of tags (string, note * means everything) to expirations, and we track the creation time against each CacheItem
• when fetching items from L1 (in-proc) cache, we check the item's creation data against the cache's wildcard and per-tag expirations; if the creation date is earlier than any of these: it is treated as disallowed
• to allow persistence of invalidation between sessions when a L2 (backend cache) is in play, we additionally store the timeout data via additional simple values in the cache
• we also pre-fetch any missing tag data from L2 as-needed, and enforce the previous expirations
• to facilitate this, and allow reliability that the data we are parsing is the data requested: the data stored in L2 is now embedded inside a payload that includes the creation timestamp, duration, key, tags, etc as well as the payload
• in the rare event that the L2 data contains additional tags to those advertised by the caller: these additional tags are also fetched and enforced

Because the tag fetches are async, the data in the lookup is not (timestamp), it is Task<(timestamp)>

Outstanding:

• additional logging
  • add log when L2 data is rejected for (reason)
  • add metric of the number of tag expirations being tracked in L1

Microsoft Reviewers: Open in CodeFlow

[sebastienros]

I am not sure GetTimestamp() should be used to store the moment, I tried this code on Linux and Windows and got different results:

Console.WriteLine(TimeProvider.System.GetTimestamp());
Console.WriteLine(TimeProvider.System.GetUtcNow());
Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.OSDescription);

8226721287470
12/20/2024 5:27:32 PM +00:00
Microsoft Windows 10.0.17763

5640002254299340
12/20/2024 17:27:24 +00:00
Ubuntu 24.04.1 LTS

[mgravell]

@sebastienros thanks, great catch! I incorrectly assumed that this was a defined value like epoch ticks or something. Apparently not. I'll rework that into something reliable.

[mgravell]

There is TimestampFrequency, but I will change to use GetUtcNow() instead.

[sebastienros]

Use ticks (but same normalization issue) or a sortable numeric format (yyyymmddhhmmssxxxx), or use an EPOCH so 0 starts at 1/1/2025 ;) then numbers are much smaller.

[mgravell]

I considered that - if you think it won't be contentious, sure I can use an atypical epoch. At stackoverflow, we used "stack seconds" in a few key places :) however, the fixed size is highly desirable, and I'd rather not get into 32-bit pain. Honestly, I think it is better to just pay for 64 and not worry about it.

[jodydonetti]

FWIW DateTimeOffset.Ticks/UtcTicks seems to be consistent cross platform.

[mgravell]

rebase went really, really freaky; trying to resolve, but it might be easier to re-branch and copy just the HC bits

[mgravell]

moving to #5781 due to rebase fail

re the GetTimestamp() usage; upon review, the only place I could find that was in the tests where it was only used for "is it the same now?", but: that has now been removed (/cc @sebastienros )