You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Aleksander Nek (Jira)" <ji...@apache.org> on 2026/09/29 13:27:00 UTC
[jira] [Updated] (RANGER-5813) GraalJS ScriptEngine is not closed after Ranger resource expression evaluation, causing JVM heap growth
[ 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)