[jira] Resolved: (EL-5) [el] Contention on global cache / parseExpression

["Matt Benson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/EL-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Benson resolved EL-5.
--------------------------

    Resolution: Fixed

Applied the change that saves the parse results in the JSTLExpression objects.  I didn't feel good about applying the change that continually created new HashMaps, so I addressed the thread competition issue by removing the synchronization altogether; the worst that can happen is that multiple threads may write the same value into the map but once the initial few passes of this have taken place there should be no further effects beyond the avoidance of synchronization locks.

> [el] Contention on global cache / parseExpression
> -------------------------------------------------
>
>                 Key: EL-5
>                 URL: https://issues.apache.org/jira/browse/EL-5
>             Project: Commons EL
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Matthias Ernst
>             Fix For: 1.1
>
>         Attachments: patch, patch-el-cache.txt
>
>
> The ExpresssionEvaluatorImpl maintains a static synchronized hashmap as a global
> parser cache. In my tests, this proves to be a contention point in highly
> concurrent web access, even if the cache is already filled:
> "tcpConnection-8080-514" daemon prio=1 tid=0x08214890 nid=0x4e39 waiting for
> monitor entry [bd9ff000..bd9ff908]
>         at java.util.Collections$SynchronizedMap.get(Collections.java:1942)
>         - waiting to lock <0x45586ef0> (a java.util.Collections$SynchronizedMap)
>         at
> org.apache.commons.el.ExpressionEvaluatorImpl.parseExpressionString(ExpressionEvaluatorImpl.java:306)
> ...
> Even pre-parsing the expressions through #parseExpression doesn't help: it
> parses the expression for syntactic correctness and returns an instance of
> JSTLExpression that, however, doesn't contain the parsing result. It is reparsed
> on every evaluation.
> I propose
> * evaluator instance local caches that still need synchronization, but can be
> made thread-local, page-local oder whatever by the calling application / container.
> * to actually maintain the parsing result in JstlExpression
> I would volunteer to develop the respective patches, if desired.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.