On 17/02/2012 21:13, Gary Gregory wrote: > So... are we ready to move some bits? > ;)
Getting there. I had some Tomcat stuff to do. I'll try and look at this this week. Mark > Gary > > On Sun, Feb 12, 2012 at 8:03 PM, Konstantin Kolinko > <knst.koli...@gmail.com>wrote: > >> 2012/2/13 Mark Thomas <ma...@apache.org>: >>> >>> General >>> - Logging in pool, if any, should be minimal >>> >> >> Two general questions: >> When there are several pools, >> - is it possible to discern log messages from different pools? >> - is it possible to control logging level for a single pool, or all >> pools have the same logging configuration? E.g. to enable debug >> logging for a single pool only (if debug logging is ever implemented >> there). >> >>> >>> What do folks think to the following solution: >>> - make logging of factory exceptions a factory responsibility - clearly >>> documented in the JavaDoc for POOL2 >>> - add some JMX stats to POOL2 for number of destroy / passivate / >>> activate exceptions >>> - make the last n (10?) exceptions of each type accessible via JMX for >> POOL2 >>> ? >>> >> >> Overall this proposal looks good, but there is known caveat with >> keeping Exception instances in memory: Their stacktrace data is known >> to pin classloaders in memory, preventing them from being garbage >> collected and thus causing PermGen memory leaks in web applications. >> >> This problem was reproduced in this Tomcat issue: >> https://issues.apache.org/bugzilla/show_bug.cgi?id=50460 >> Discussion: >> http://marc.info/?l=tomcat-dev&m=129211856426188&w=2 >> >> A workaround might be to print stacktraces as strings and keep the >> strings in memory, but it may be time-consuming. The good point though >> is that the time to print those exceptions to strings is comparable >> with the one spent when printing them to a log file. >> >> Best regards, >> Konstantin Kolinko >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
