commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Benson (JIRA)" <>
Subject [jira] Reopened: (EL-5) [el] Contention on global cache / parseExpression
Date Sat, 11 Aug 2007 14:47:43 GMT


Matt Benson reopened EL-5:

Thanks--I quite obviously hadn't encountered this before, and had the same assumptions regarding
-not- synchronizing HashMap access as the poster.  To answer your question, I have not measured
that creating these maps again and again is a problem, but that does not stop me from having
a general distaste for wantonly copying a potentially large table again and again.  I will
certainly revert my uninformed removal of the synchronization here (I fail to see why the
code uses C.synchronizedMap(new HashMap()) as opposed to Hashtable since I can't see that
either key or value would ever be null), but since the symptom here is performance degradation
it might well be that a more "correct" solution would be load-balancing with another JVM.

Perhaps we can compromise by ensuring that the API here allows you to subclass for the behavior
you want.

> [el] Contention on global cache / parseExpression
> -------------------------------------------------
>                 Key: EL-5
>                 URL:
>             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(
>         - waiting to lock <0x45586ef0> (a java.util.Collections$SynchronizedMap)
>         at
> org.apache.commons.el.ExpressionEvaluatorImpl.parseExpressionString(
> ...
> 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.

View raw message