java - setContextClassLoader implications -


similar question: setcontextclassloader implications, trying clean warnings memory leaks. specifically, have servlet code follows:

public void doget(httpservletrequest httprequest,          httpservletresponse httpresponse) throws servletexception, ioexception {     class basicthread extends thread {         public void run() {             // finite amount of stuff here         }     }     thread thread = new basicthread();     //thread.setcontextclassloader(null);     thread.start(); } 

this article: http://wiki.apache.org/tomcat/memoryleakprotection#cclthreadspawnedbywebapp, indicates if uncomment setcontextclassloader line, error messages go away.

but question is: there memory leak? if so, don't want make warnings go away, want fix leak. how do so?

thanks.

(also, if change line "// finite amount of stuff here" "// infinite amount of stuff here (ie, loop forever)", proper way of ensuring no memory leaks in scenario?)

this real issue if following true. 1. thread never stops, if thread never stops there no gc root , classloader can never garbage collected. 2. application doing hot deployments should take account.

the underlying issue is, when want un-deploy , re-deploy, application server want gc war's classloader. if war has created thread referencing war's classloader , thread has not completed classlodaer can never garbage collected , see out of memory: permagen.

if restart server (and jvm) each deployment issue wouldn't manifest.

i read through article posted , describe suggested

severe: web application appears have started thread named [leakingthread] has failed stop it. create memory leak.

for more of point of reference, asked similar question regarding classloader leaks.


Comments

Popular posts from this blog

c# - How to set Z index when using WPF DrawingContext? -

razor - Is this a bug in WebMatrix PageData? -

android - layout with fragment and framelayout replaced by another fragment and framelayout -