[EL-5] [el] Contention on global cache / parseExpression

• Type: Bug
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.0
• Fix Version/s: 1.1

Environment

Operating System: other
Platform: Other

• Bugzilla Id: 24286
• Assignee: Unassigned
• Reporter: Matthias Ernst
• Created: 31/Oct/03 18:09
• Updated: 22/Feb/11 06:34

Description

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.