Vous trouverez ci-dessous une sortie d'entrées uniques dans mon fichier catalina.out sur Centos Machine. Je couronne Tomcat 6 avec le printemps 3 et ma demande. Il y a des tas d'entre eux, donc je viens de choisir certains qui continuent à répéter. Cela n'arrive pas tout le temps mais cela arrive au moins une fois par semaine.
Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [] registered the JBDC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [] appears to have started a thread named [com.iteezy.shared.domain.DirEntry.data] but has failed to stop it. This is very likely to create a memory leak. Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [] appears to have started a thread named [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0] but has failed to stop it. This is very likely to create a memory leak. Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [] appears to have started a thread named [File Reaper] but has failed to stop it. This is very likely to create a memory leak. Feb 3, 2011 2:37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [] appears to have started a thread named [pool-1-thread-22] but has failed to stop it. This is very likely to create a memory leak. 37:48 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads b application [] appears to have started a thread named [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2] but has failed to stop it. This is very likely to create a memory leak. 37:48 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap b application [] created a ThreadLocal with key of type [net.sf.json.AbstractJSON$1] (value [net.sf.json.AbstractJSON$1@40bbb3d6]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak.
3 Réponses :
Arrêtez votre webApp correctement. Ne laissez pas ces discussions en cours d'exécution.
Alternativement, ne gardez pas le redéploiement de la webApp.
Ceci est un conseil assez inutile, semblable à "dire non". L'OP éteignait correctement la webapp à son esprit, car une caractéristique de Tomcat (et presque tous les autres récipients de servlet) consiste à arrêter des webapps sans codage spécial requis. Le commentaire de Tomascz non seulement décrit ce que le message d'erreur n'était que sur la manière de le suivre.
Configurez un servlet pour le gérer dans son Dans votre servlet, procédez comme suit dans la méthode Destroy. Vous devrez évidemment avoir accès à une collection détruire () code> méthode. Les threads peuvent vérifier un drapeau pour voir s'ils doivent continuer ou non. public class MyThread {
private boolean finished = false;
@Override
public void run() {
while (!finished) {
//do something
}
}
public void stopProcessing() {
finished = true;
}
}
Est-ce que je remplace la méthode Détruire sur chaque servlet sur mon système? Aussi, est-ce que je mets la classe mythread sous chaque servlet?
@Bikash non, il suffit de remplacer la détruire sur un servlet, un servlet qui n'est pas réellement appelé nulle part, mais est initié (web.xml). Ensuite, ce servlet a besoin d'un accès à une collection de fils, et elle itère à travers cette collection dans la méthode Destroy. Vous devez évidemment renoncer à cette collection lorsque des threads sont créés et vous devez vous assurer que les threads qui se terminent avant que Tomcat ne soit fermé de la collection, sinon vous obtiendrez des fuites de mémoire!
Terminé doit être Volatile , pourquoi ne pas simplement utiliser le drapeau interrompu existant disponible pour chaque thread? Voir: Stackoverflow.com/Questtions/7786305
Lorsque vous définissez un drapeau externe selon lequel un thread est supposé à sonder et à quitter lorsqu'il est défini - il doit être Cependant, il existe déjà une fonctionnalité comme celle de l'API standard - elle s'appelle une interruption qui étant dit appelant La ligne de fin de la ligne est la suivante: vous ne pouvez pas simplement tuer tout ce qui bouge (en fait, Tomcat fait cela pour vous après avoir délivré cet avertissement), mais déterminez où les threads proviennent et utilisent le framework / la bibliothèque spécifique volatile . Sinon, le fil peut ne jamais voir le changement fait par un autre fil.
interruption () méthode et thread.CurrentTthread (). Isinterrupted () . Pas besoin de dupliquer la logique déjà existante. Voir: Arrêter un thread Java spécifique .
interruption () sur chaque thread est une mauvaise idée, car il n'y a aucune garantie que tous les threads y répondent. Examinant vos exceptions, j'ai remarqué que les threads suivants ne sont pas nettoyés correctement:
com.mchange.v2.async.threadpoolasynchronousrunner $ piscineThead- # 0 - Fermez la source de données C3P0. Puisque vous utilisez le ressort, ajoutez simplement détruire-méthode = "Fermer" . Nous avons fini avec ce fil.
File Reaper - Autant que je puisse voir que ce thread est créé par FileCleaningTracker . Vous devez appeler filecleaningtracker.exitWhenFinehed () explicitement lors de la fermeture de votre application (ou lorsque la classe n'est plus nécessaire, je ne l'ai jamais utilisée) ou je ne le fais pas ressort (voir ci-dessus). Les chances sont une bibliothèque de 3ème partie l'utilise et ne ferme pas correctement - cela signifie qu'il a un bogue.
piscine-1-thread-22 - Ceci est l'une des threads créés par Exécuteurs utilitaire à l'intérieur ExecuTelservice . Assurez-vous d'appeler shutdown () sur chaque piscine de votre application lors de l'arrêt.
org.springframework.scheduling.quartz.schedulerfactorybean # 0_worker-2 - thread de travailleur de quartz (celui qui exécute effectivement des emplois). SchedulerFactoryBean ferme le planificateur pour vous automatiquement, je pense que Tomcat est erroné ici, je vois aussi cette erreur souvent. Néanmoins ressemble à la réglage plancheferfactorybean.waitforjobstocompleteonshutdown to true résout ceci.
com.iteur.shared.domain.direntry.data - Je ne suis pas sûr de celui-ci. C'est soit votre propre thread qui doit être interrompu lors de l'arrêt ou du fil de la base de données H2 (?) Sa pile doit être examinée pour deviner d'où vient-il.
fermer () méthode pour permettre un nettoyage ultérieur. Être doux.