How would one inspect the contents of the cache?

[blakepell]

The Dictionary list of Keys is not exposed in the MemoryCache class like it was in previous implementations (I believe this currently tracked in the _entries variable). I understand, the argument is that the list could be stale or even go stale as you iterate through it (I still think the benefit outweighs the known risk).

My issue is, how would someone inspect the contents of the cache in a diagnostics scenario? It seems like an awful lot of overhead to implement a cache manager of what might be there when the underlying Dictionary of keys could just be exposed like in past implementations (yes, it could be gone even during the iterating loop but it could also be gone at any request even if I'm tracking it). In the past this was blocking and not recommended for production environments (from MS documentation) but there are reasonable environments where you may want to do this (and the information is valuable when it's needed).

As reference, the Count property exposes the underlying dictionaries count with the comment "Gets the count of the current entries for diagnostic purposes".

I was able to fork the project, expose the keys and replace that assembly via a custom nuget feed. Is it possible to inspect the cache without an intervention like this?

[muratg]

I don't think exposing the keys is the right default, because of the risks. Folks will just use it without knowing the risks.

If you really want to do this, I think instead of forking the code and exposing it in your fork, I recommend writing a wrapper which basically saves and deletes the keys in Set and Remove operations after calling our cache's respective methods.

[blakepell]

There are lots of useful things that people could misuse.

Is this not something that could be explained briefly in the XML comment that Intellisense would then render? E.g. "Returns dictionary enumerator used to iterate through keys in the cache. This is a blocking call with the keys as of a point in time.". That makes it's behavior clear and allows me to accept (or not) the now known risk.

Writing a wrapping manager is ok for when I add something into the cache via code but there are other entry points into the cache like the cache tag helper or even third party controls that may have a behavior that's out of my control. With no way to inspect it's full contents easily it's incredibly difficult identify an issue like that.

Thank you for your response also, it is appreciated.

[muratg]

Inviting @lodejard to chime in too.

cc @Eilon

[Eilon]

My philosophical view is that it's definitely a wrong API to have. This type of cache is deliberately unpredictable so listing keys is not logical.

But the diagnostics scenario is definitely interesting. Would it make more sense to just have some diagnostics feed of data from the cache system? Then anyone wishing to introspect into the cache could go through some different API? You could even maybe get other information about hits/missed/size/etc.?

[blakepell]

I would welcome an alternative API route, that would alleviate my issues. That data would be incredibly useful in debugging and fine tuning (and getting additional data like size is more than we've had in the past). Knowing hits and misses or even the life of some objects and be useful in finding misuses (or rather mistakes) in using the cache.

Would you see the separate API including the keys (or at least where the objects originated from)? More from the perspective of the key name can be helpful identifying information if it has been meaningfully named.

[Tratcher]

Something like DiagnosticsSource? https://github.com/aspnet/Caching/issues/129

[Eilon]

@Tratcher not like it, but exactly it 😄

[muratg]

Yeah, https://github.com/aspnet/Caching/issues/129 seems to be the right way for diagnostics. @blakepell would the general proposal outlined there be helpful to you?

[blakepell]

@muratg - Yes, very much so. #129 as it reads would cover want I wanted to address (and more).

[muratg]

Cool, tagged you in that issue so that you're notified when the issue changes. Closing this one.