You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Alex Deparvu (JIRA)" <ji...@apache.org> on 2018/10/24 09:58:00 UTC

[jira] [Created] (OAK-7860) Make PermissionEntryCache more resilient against OOME

Alex Deparvu created OAK-7860:
---------------------------------

             Summary: Make PermissionEntryCache more resilient against OOME
                 Key: OAK-7860
                 URL: https://issues.apache.org/jira/browse/OAK-7860
             Project: Jackrabbit Oak
          Issue Type: Improvement
          Components: core
            Reporter: Alex Deparvu
            Assignee: Alex Deparvu


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 [0]. 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.


[0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/permission/PermissionEntryCache.java#L74



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)