[ http://issues.apache.org/jira/browse/EL-5?page=all ]
Matthias Ernst updated EL-5: ---------------------------- Attachment: patch-el-cache.txt I have stumbled over this again. The synchronized map proves to be a point of contention in an application that runs on a highly concurrent machine (Sun T2000 w/32 cores) with JSPs that contain many EL expressions. Several hundred hits/s times several ten expressions/JSP leads to several (ten) thousand ELuations per second. The simplest patch that could possibly work is as follows: instead of using a mutable, synchronized hashmap, use an immutable, copy-on write table where only the access to the cache field itself is protected through a monitor. A corresponding patch is attached. [With Java 5, this monitor-protected field could even be replaced through a volatile field. Doing so is legal under the revised memory model and produced even more throughput in my non-trivial testcase.] > [el] Contention on global cache / parseExpression > ------------------------------------------------- > > Key: EL-5 > URL: http://issues.apache.org/jira/browse/EL-5 > Project: Commons EL > Type: Bug > Versions: 1.0 Final > Environment: Operating System: other > Platform: Other > Reporter: Matthias Ernst > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]