https://issues.apache.org/bugzilla/show_bug.cgi?id=54217
--- Comment #12 from Levan <informatik0...@gmail.com> --- (In reply to Mark Thomas from comment #11) > There are two separate issues in this report and WONTFIX is not the correct > status for either of them. > > The actual memory leak found while investigating this bug has been fixed in > 7.0.34 onwards as per comments #4 to #6. > > The issue of the connections not being closed on reload is a result of the > J2EE specification for JNDI resources and this part of the bug report is > therefore invalid. > > I am restoring the state of this bug to fixed to reflect that the memory > leak that did exist has been fixed. > > To expand on why the failure to immediately close connection after reload is > invalid, the J2EE specification provides no mechanism for the container to > tell the resource it is no longer required. Therefore all the container can > do is clear references to the resource and wait for garbage collection > (which will trigger the closure of the pool and the associated connections). > > Garbage collection occurs at times determined by the JVM so this is why it > takes an indeterminate amount of time for connections to be closed after a > context reload as a garbage collection may not occur for some time. > > Tomcat has added the Tomcat specific JNDI attribute closeMethod which can be > used to trigger the explicit close of a JNDI resource when a context is > stopped. If waiting for GC to clean up resources is not acceptable then > simply use this parameter. Tomcat does not use this by default as it may > have unexpected and unwanted side-effects for some JNDI resources. > > If you'd like to see a standard mechanism provided for telling JNDI > resources that they are no longer required then you need to lobby the J2EE > expert group. Thank you Mark for the explanation. I'll make a now third update to my Stack Overflow page and post this comment there. I knew it, it also had to do be about garbage collector. Again thanks! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
