Symptom: all processor threads spin madly in: ============== "tomcat-processor-20" daemon prio=10 tid=0x09210800 nid=0x51fb runnable [0x61b76000] java.lang.Thread.State: RUNNABLE at java.util.HashMap.getEntry(HashMap.java:347) at java.util.HashMap.containsKey(HashMap.java:335) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:227) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) ... ============== Cause: org.apache.catalina.security.SecurityUtil.objectCache is a HashMap, but access to it is not synchronized. The javadoc for HashMap says: ============= Note that this implementation is not synchronized. If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. ============= Proposed solution: change objectCache to ConcurrentHashMap;
That may not be the only bug. There are two instances of the following code: if(objectCache.containsKey(targetObject)){ methodsCache = objectCache.get(targetObject); If the object is removed between the two statements, then an NPE will follow. Surely the code should just check whether it got a non-null object? Also, the private static fields should be final.
Thanks for the report. Fixed in trunk for 7.0.5 onwards and proposed for 6.0.x
Fixed in 6.0.x and will be included in 6.0.30 onwards.
Thanks for prompt fix, waiting for 6.0.30.