You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mock response for existing mocks will be cached whenever a mock endpoint is invoked by a client. A unique hash will be generated using the following parameters to be used as the cache key
When a new mock gets created, the same unique parameters mentioned above will be used to generate an unique hash for the key
Eviction
The cache will be evicted based on sliding expiry policy. The cache that has not been accessed for the past 60 minutes will be evicted
** The entire cache will be evicted when a mock is updated or archived. The thought process behind this decision is that when the user updates an existing mock, then evicting the unique mock will not be possible if a client has already triggered the caching with a different set of request headers. This will lead to inconsistencies if we try to evict a cache based on the unique key generated from the mock fetched from the Database
E.g:
Let's assume "client-x" invokes a "mock_a" with the following request headers
- Authorization
- Content-type
- Host
These headers will decide the cache key. However, it is not necessary for the mock stored in the DB to have the same set of headers if strict header matching is not enabled for the mock.
In this case, if the user updates "mock_a", then the eviction will not remove the mock data from the cache as the hashed key will be different. Hence, all the existing cache needs to be evicted to ensure consistency
Summary
Explore springboot caching to enable it for mock responses. Use the hash generated from the request body + headers as the key for the cache
Scope of the issue
To improve mock response performance
Impacted area
Supporting artifacts
No response
The text was updated successfully, but these errors were encountered: