[
https://issues.apache.org/jira/browse/OGNL-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445840#comment-17445840
]
Pascal Davoust commented on OGNL-261:
-------------------------------------
Just opened PR [https://github.com/jkuhnert/ognl/pull/138] against master.
Please note that this implies that JDK 1.7+ is used.
I could not find any other explicit JDK minimal requirement apart from the
project POM itself which compiles against JDK 8 (master branch).
[~lukaszlenart] Any backport applicable to other branches I should look at?
I also looked for any kind of OGNL benchmark to measure the benefits, but could
not find any.
So I ran and profiled our full application stack with the original code and
with the code from the PR, and here are the results, for what it's worth:
* With stack traces captured in {{OgnlException}}: 3.5% CPU time spent in
{{new OgnlException(...)}}
* Without stack traces captured in {{OgnlException}}: no more CPU time spent
in {{OgnlException}}
> Avoid collecting stacktrace when building an OgnlException
> ----------------------------------------------------------
>
> Key: OGNL-261
> URL: https://issues.apache.org/jira/browse/OGNL-261
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
> Reporter: Pascal Davoust
> Priority: Major
>
> Spin-off discussion from WW-5147 and related
> [https://github.com/apache/struts/pull/504] pull request.
> Whenever an OGNL expression compiles into an AST with compound node
> statements, the evaluation can result into a {{{}OgnlException("source is
> null for getProperty(null, "propertyName")"){}}}.
> This stems from the logic in method {{ognl.ASTChain.getValueBody(OgnlContext,
> Object)}} which uses the result of the current node as the source for the
> next node in the chain.
> If the result of the current node evaluation results into {{{}null{}}}, then
> the next node throws the exception.
> As mentioned in [https://github.com/apache/struts/pull/504], there is a
> question about whether this logic is by design or if there is something to
> investigate (I definitely lack background and OGNL knowledge to even guess).
> If this behavior is legitimate, it also turns out that this situation occurs
> a lot and the cost of building the exceptions with the stack traces is fairly
> noticeable: profiling the code while under load shows a significant amount of
> time spent building the stack traces.
> Depending on the outcome of the discussion above, would it make sense to
> envision to allow OGNL to throw these exceptions without the stack traces if
> configured so (which can be easily done from JDK 7 using the constructor
> taking the {{enableSuppression}} and {{writableStackTrace}} arguments - can
> also be achieved from older JDKs by overriding method {{fillInStackTrace()}}
> )?
> Note that a preliminary attempt showed that the cost of building these
> exceptions without the stack traces is virtually zero, making the exceptions
> totally painless and invisible (they appear no more while profiling).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
