[
https://issues.apache.org/jira/browse/EL-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519307
]
Matthias Ernst commented on EL-5:
---------------------------------
> Perhaps we can compromise by ensuring that the API here allows you to
> subclass for the behavior you want.
That's evading the problem and continuing to ship an inadequate implementation.
> having a general distaste for wantonly copying a potentially large table
> again and again
I am all for having taste about code but you should apply some reality checks.
How many distinct EL expressions are there in an application do you think? I
counted petstore and appfuse - yes both are sample applications - they have 60
resp. 80 lines with EL in it, maybe multiple per line. Let's assume a real
application is much bigger, with 1000 distinct EL expressions in it. How
expensive is that gonna be?
HashMap<String, String> hashMap = new HashMap<String, String>();
for(int i=0; i<1000; i++) {
hashMap = new HashMap<String, String>(hashMap);
String s = "expression" + i;
hashMap.put(s, s);
}
This takes 300ms on my MacBook. Make it 10000 expresions - 7 seconds. Who's not
willing to invest these seconds for increased scalability over the whole uptime
of his app? I'm sure these seconds are paid off way faster than you think.
Maybe the people on this ticket can share their experiences with the patch?
> [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.
