That seemed pretty rare to me - that there were so many EL's that it had blown memory.
Matthias' example above of having lots of contention because a (relatively) small number of ELs are accessed again and again and again sounds much more likely.
This is also all very similar to LANG-334 where the same optimized synch-write-copy approach is suggested by Jason Madden. I'm drawn to the simpler synchronizedMap without knowing what kind of performance improvements are likely from the sync-write-copy.
Matthias' example above does contain data - at least it contains 1000 entries at the end. However 7 seconds per new EL seems very bad. A new JSP page is hit with a dozen EL statements in that are new and you're looking a minute+ of hanging.
> [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)
> 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.