[
https://issues.apache.org/jira/browse/RANGER-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksander Nek updated RANGER-5813:
-----------------------------------
Description:
When a policy resource contains a request expression, for example
database=${{{}REQ.user.replace(/-/g, '_'){}}}, Ranger evaluates it during
resource matching.
The call path is ResourceMatcher.getExpandedValue() →
RangerRequestExprResolver.resolveExpressions(RangerAccessRequest) →
ScriptEngineUtil.createScriptEngine() →
GraalScriptEngineCreator.getScriptEngine().
RangerRequestExprResolver creates a new ScriptEngine for each evaluation but
never closes it. With GraalJS 25.1.3, the resulting engines remain reachable
after garbage collection. Under normal authorization traffic, this causes
sustained JVM heap growth in the service hosting the Ranger plugin.
In one Impala coordinator investigation, a live class histogram showed 2,530
RangerRequestScriptEvaluator instances and approximately 1,568 MiB of retained
GraalJS objects. A standalone reproduction using the same engine creation
pattern retained 200 engines after 200 evaluations; explicitly closing each
engine kept the registry and heap bounded. Disabling the policy containing the
expression stopped the observed growth.
was:
When a policy resource contains a request expression, for example
database=${\{REQ.user.replace(/-/g, '_')}}, Ranger evaluates it during resource
matching.
The call path is ResourceMatcher.getExpandedValue() →
RangerRequestExprResolver.resolveExpressions(RangerAccessRequest) →
ScriptEngineUtil.createScriptEngine() →
GraalScriptEngineCreator.getScriptEngine().
RangerRequestExprResolver creates a new ScriptEngine for each evaluation but
never closes it. With GraalJS 25.1.3, the resulting engines remain reachable
after garbage collection. Under normal authorization traffic, this causes
sustained JVM heap growth
in the service hosting the Ranger plugin.
In one Impala coordinator investigation, a live class histogram showed 2,530
RangerRequestScriptEvaluator instances and approximately 1,568 MiB of retained
GraalJS objects. A standalone reproduction using the same engine creation
pattern retained 200
engines after 200 evaluations; explicitly closing each engine kept the
registry and heap bounded. Disabling the policy containing the expression
stopped the observed growth.
> GraalJS ScriptEngine is not closed after Ranger resource expression
> evaluation, causing JVM heap growth
> ---------------------------------------------------------------------------------------------------------
>
> Key: RANGER-5813
> URL: https://issues.apache.org/jira/browse/RANGER-5813
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
> Reporter: Aleksander Nek
> Priority: Major
>
> When a policy resource contains a request expression, for example
> database=${{{}REQ.user.replace(/-/g, '_'){}}}, Ranger evaluates it during
> resource matching.
> The call path is ResourceMatcher.getExpandedValue() →
> RangerRequestExprResolver.resolveExpressions(RangerAccessRequest) →
> ScriptEngineUtil.createScriptEngine() →
> GraalScriptEngineCreator.getScriptEngine().
> RangerRequestExprResolver creates a new ScriptEngine for each evaluation but
> never closes it. With GraalJS 25.1.3, the resulting engines remain reachable
> after garbage collection. Under normal authorization traffic, this causes
> sustained JVM heap growth in the service hosting the Ranger plugin.
> In one Impala coordinator investigation, a live class histogram showed 2,530
> RangerRequestScriptEvaluator instances and approximately 1,568 MiB of
> retained GraalJS objects. A standalone reproduction using the same engine
> creation pattern retained 200 engines after 200 evaluations; explicitly
> closing each engine kept the registry and heap bounded. Disabling the policy
> containing the expression stopped the observed growth.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
