DO NOT REPLY [Bug 24286] New: - Contention on global cache / parseExpression

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24286>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24286

Contention on global cache / parseExpression

           Summary: Contention on global cache / parseExpression
           Product: Commons
           Version: 1.0 Final
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: EL
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: matthias.ernst@coremedia.com


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.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org