There is this part in the configuration
//Optional max cache size in entries for storing surrogate template id mappings. Defaults to None
max-template-id-cache-entries = 1000
Does this mean that the cache will store data for at most 1000 (Template, User) pairs?
Even though it’s often referred to as a cache and entries in the query store do get stale over time, the HTTP JSON API service always updates the query store to answer the query it received. As such, the HTTP JSON API service will always provide the most up-to-date answer it has access to as part of every query. It does so by maintaining some bookkeeping with regards to the last available data for each (party, template) pair. Any further inconsistency is because of the simple nature of a request taking some (usually very short, but still meaningful) time to reach its destination and come back with an answer.
Very good question, which goes back to (and slightly re-frames) what you asked previously. The HTTP JSON API service doesn’t “garbage collect” stale state, it just keeps it around to minimize the data needed to catch up with new requests which target the same (party, template) pair. As such, rather then “storing the ACS”, the real problem you might want to work against is that of ending up with a lot of stale state that will never be used to answer any query. In certain systems, it might be viable to program clients so that they periodically issue queries that cause the system to get up-to-date and flush the stale data. Other times, that stale data is not really a problem, just a consequence of certain access patterns.
If you want to control the size of the HTTP JSON API service query store, the best way to do so is to minimize the size of each instance by managing instances so that specific (party, template) pairs are managed by specific instances.
No, this setting is only related to an in-memory cache that is not related to contracts at all. (IMO this setting should be removed.)
We’re leaking the internals of the server to the client, I don’t think we want to do that. There should be some mechanism to constrain the growth and a policy to evict data.
Agreed. I was suggesting a workaround since this mechanism is currently not prioritized.