DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37837>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37837 Summary: Memory leak in mx4j with Coyote JK2/AJP 1.3 connector Product: Tomcat 4 Version: 4.1.31 Platform: Sun OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote JK 2 (deprecated) AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] JVM: Sun 1.3.1_09 Apache: 2.0.49 mod_jk: 1.2.8? Solaris 8 In load testing our server we discovered a serious memory leak in Tomcat, which seemed to be related to the number of requests being processed. Profiling with OptimizeIt showed several hundred thousand instances of javax.management.ObjectName, all held by a static Hashmap cache in the same class. This appears to be a bug in the ObjectName class in mx4j 1.1.1, which is used by Tomcat. The ObjectName class caches all instances it has created, to avoid parsing new object names if this has already been done once. However, the creation of ObjectNames in org.apache.jk.common.ChannelSocket.registerRequest() creates a unique name for every request registered, so the cache grows endlessly. In later versions of mx4j, this cache has been changed to use weak references, and additionally is only used when a special system property is set. We have worked around the problem by hacking up a version of ObjectName which disables the cache (email jdickson at dialectsolutions dot com for a copy). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
