[
https://issues.apache.org/jira/browse/EL-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519324
]
Matt Benson commented on EL-5:
------------------------------
Thanks for the example. I do note that your example Map doesn't actually
contain any data. In my sad, disillusioned state I entertain the notion that a
populated map might take longer to copy than an empty one. Further I am not
thinking here so much of execution time as I am of the number of object
instances floating around. I'm sorry you view my suggestion of compromise as
an evasion. We may well never see eye-to-eye here due to the simple fact that
your position is based on real-world examples but mine must be based on any
forseeable possibilty, rather than only the most likely ones. Your situation,
as I suggested before, could be interpreted as a matter of your having exceeded
the number of concurrent clients el can reasonably support in a single JVM. If
you then have the option to configure the library such that you can apply your
solution, while not forcing it on that theoretically possible application that
continues to have new expressions thrown at it, why is that such an insult?
Given that you reported this issue on the order of four years ago, I would
think that you might welcome any forward movement, rather the acerbic reception
I'm seeing here.
> [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.
