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=43636>. 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=43636 Summary: Redeployment should replace all Threads with new Threads to clear ThreadLocals Product: Tomcat 6 Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tomcat should end all (Connector-)Threads after a redeployment. This may be configurable. _______________________________________________________ Reason for OutOfMemory: After several redeployments I get always an OutOfMemory-Error. Tracking down this bug, I identified several causes, which are widely discussed, eg. http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang or http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 Several of the bug (e.g. Commons Logging) are based on the usage of ThreadLocal. Additional, ThreadLocals used in static fields prevents the unloading after a redeployment completely: HttpThread.threadLocal -> Thread$ThreadLocalMap$Entry.fieldValue -> OwnClass.$class -> OwnClass.class.classLoader -> ClassLoader.classes -> OtherClass.myStaticThreadLocal -> myThreadLocal-Instance which prevents the release of myThreadLocal, which is never released as long as the Thread exists. The threadLocal itself is reached through strong references. _______________________________________________________ Particular problem with log4j: Now I get stuck on our configuration of log4j/commonslogging, which holds a reference to our (undeployed) webappliation: [1634]: 67mb ApplicationShutdownHooks.class hooks: 67mb IdentityHashMap *: 67mb Catalina$CatalinaShutdownHook "Thread-52" server: 66mb StandardServer services: 65mb Service[] *: 65mb StandardService "Catalina" connectors: 65mb Connector[] *: 65mb Connector protocolHandler: 65mb Http11Protocol tp: 63mb ThreadPool "http-8080" threads: 63mb Hashtable *: 63mb ThreadWithAttributes inheritableThreadLocals: 63mb > *: 31mb ContextMap [EMAIL PROTECTED] > $class: 31mb ContextMap.class [EMAIL PROTECTED] $classloader: 31mb WebappClassLoader [EMAIL PROTECTED] classes: 31mb Vector *: 29mb NewGeoLocator.class .... _______________________________________________________ A simple solution for this problem would be the termination of all processing threads. After every redeployment: - All threads in the pool should be terminated. - Working threads should be terminated instead of putting back into the pool. - Connection-Keepalives should be terminated if the threads recognizes a redeployment. I know, this solves not the main reason for the OutOfMemory, but its easy to implement and prevents many OutOfMemories due to ThreadLocal problems. A cleaner solution may be to clear any of the problems in the library (log4j/commonslogging) or in the own problem. But even in well designed programs, unexpected exception may skip the cleanup code, unless we write huge amounts of nested try/finally statements. So I suggest simply the termination of all threads after any redeployment with a new configuration option (restartThreadsAfterRedeployment). -- 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]
