https://issues.apache.org/bugzilla/show_bug.cgi?id=53085
Bug #: 53085
Summary: [perf] [concurrency]
DefaultInstanceManager.annotationCache is not optimal
for more threads
Product: Tomcat 7
Version: 7.0.26
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: Catalina
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
Created attachment 28616
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28616
Screenshot : Thread states during test
This is a small Concurrency problem also find during myfaces performance
testing [1]
org.apache.catalina.core.DefaultInstanceManager.annotationCache uses
WeakHashMap for cache, but this approach needs sychronized get() access. This
can lead to complete thread stuck at this lock - see attached screenshots from
yourkit profiler.
I think this problem is classical concurrent cache problem = many read but only
few put()s, reads vastly outnumber writes. It this case is should be read
without locking otherwise it is a concurrency bottleneck.
I didn't check the code of DefaultInstanceManager deeply, following are
suggestions only:
1) Normally is this concurrent-cache solvable with ConcurrentHashMap or with
maps based on this type like [2] or [3]
2) the 'weakness' can achieved with String (classname) if it is acceptable to
maintain annotations for class that can be already unloaded or with
WeakReference
[1] http://tomcat.markmail.org/thread/7bbvzmkvyvryvn44
[2]
http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/util/ConcurrentLFUCache.java
[3] http://code.google.com/p/guava-libraries/wiki/CachesExplained
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
