commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JEXL-146) Performance problem in Interpreter.unknownVariable mechanism
Date Wed, 01 Oct 2014 12:07:33 GMT

    [ https://issues.apache.org/jira/browse/JEXL-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154717#comment-14154717
] 

Henri Biestro commented on JEXL-146:
------------------------------------

An Interpreter instance is created for each expression/script execution; it should not be
possible to share an interpreter between 2 threads so the thread safety (of isStrictEngine)
is not really a concern. The only exception is the 'cancelled' flag which allows thread cancellation
of a script running as a callable.
You are however absolutely right about the potential issue with the functors; these should
definitely not be shared between interpreter instances. I've made corrections accordingly;
Closure/callable no longer acquire a reference to their caller functor. Thanks for spotting
the issue.


> Performance problem in Interpreter.unknownVariable mechanism
> ------------------------------------------------------------
>
>                 Key: JEXL-146
>                 URL: https://issues.apache.org/jira/browse/JEXL-146
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 2.1.1, 3.0
>            Reporter: David Maplesden
>
> When JEXL is used in non-strict mode it silently ignores unknown variables.  However
it still constructs a {{JexlException.Variable}} exception, even though it doesn't throw it.
> Constructing exceptions in Java is expensive.  If you happen to have a situation where
unknown variables are common then this becomes a performance problem.  It is showing up as
an issue in our application.
> Inspecting the source of {{Interpreter}} it looks like a similar issue could also occur
with a number of the other exceptions.  They are always created, even if they are not going
to be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message