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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]