The PermissionEntryProviderImpl (one instance per session) is responsible for serving the permission entries. It can be backed by 2 different types of caches:
- the PathEntryMapCache which is simply a map that eagerly loads all existing permissions for a session (aka. set of principals). Used only if there are less than 250 total entries per session (all principals combined).
- The DefaultPermissionCache backed by the PermissionEntryCache. this is the fallback for the cases where the above is too expensive to use.
In some cases, even if the number of permission entries per principal is not too large, a session that accumulates large numbers of group principals (I've seen over 700 in one internal case), will always fallback to use the PermissionEntryCache.
The PermissionEntryCache is a cache that is using the principal as a key and the permission entries as values. It is aggregating 2 different types of data:
- Existing policies: maps principals to paths with (their) existing policies (regular cache stuff)
- but it also retains paths without any relevant policies for the current session, as empty sets . being a cache keyed on the 'principal', this placeholder for empty policies will be set for each principal.
I believe this second part can be responsible for a large memory footprint, which can also be amplified by the very large number of principals in the session.
I would like to propose separating the 2 sets contained in the cache, putting the non-relevant paths in a dedicated map with a fixed size.