tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 50175] Enhance memory leak detection by selectively applying methods,
Date Tue, 02 Nov 2010 10:35:07 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=50175

--- Comment #4 from Leon Rosenberg <rosenberg.leon@gmail.com> 2010-11-02 06:35:02 EDT
---
I think we should generally distinguish the different usage scenarios. 
For what I know, most people who use tomcat in production environment (in
portals or b2c sites) do not use application reloading, because their
tomcat-clusters are limited to one, main, application, and the restart of
tomcat is safer and faster as the reload. For them most of the detection (if
not all) do not make any sense:
- daemon threads will be switched off on shutdown.
- non-daemon threads will prevent shutdown and considered bugs 
- thread-local leakage is not really interested because all threads will be
shut down anyway
- what else?

Than there are developers, which maybe use war-reloading (personally i think
ctrl-c, arrow-up, enter is faster ;-) ), they will face OOM problems unless
they fix all the leaks and/or replace the libs they are using. Still, as a
developer I would like to be able to turn it, or have it off by default.

Than there are people who use application reloading in production, and the
question remains if this info is useful for the operation of the site. 

However, at least for the first category of people, who never use reloading,
this leak detection is pretty useless, isn't it? Therefor, I would support any
idea to reduce this 'in-this-usecase-unneeded-check-and-output' :-)

-- 
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message