commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Ernst (JIRA)" <j...@apache.org>
Subject [jira] Commented: (EL-5) [el] Contention on global cache / parseExpression
Date Fri, 20 Oct 2006 07:33:36 GMT
    [ http://issues.apache.org/jira/browse/EL-5?page=comments#action_12443730 ] 
            
Matthias Ernst commented on EL-5:
---------------------------------

Ravishankar, high contention on the monitor only makes things run slower. It is not a deadlock
and it should not kill your Tomcat. It might get overloaded more easily.

Jacob Hookom told me work was underway to keep EL parse trees in compiled JSPs in Jasper (Tomcat
6?). For 5.5 the problem still stands and I do not understand why noone would even bother
commenting on my really simple patch.

All it does is replace:

expr = synchronizedMap.get(s);
if(expr == null) {
  expr = parse(s);
  synchronizedMap.put(s, expr);
}

by


synchronized(lock) {
  localMap = cache;  
}
expr = localMap.get(s);
if(expr == null) {
  expr = parse(s);
  synchronized(lock) { // optional: refetch cache in case someone updated it while we parsed
    localMap = cache;   
  }
  localMap = copy(localMap);
  localMap.put(s, expr);
  synchronized(lock) {
    cache = localMap;
  }
}

For a cache miss it has three instead of two synchronized, but once the cache is filled, there's
only one very short synchronized to read the cache field.


> [el] Contention on global cache / parseExpression
> -------------------------------------------------
>
>                 Key: EL-5
>                 URL: http://issues.apache.org/jira/browse/EL-5
>             Project: Commons EL
>          Issue Type: Bug
>    Affects 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message