Discussion :

[Mengué georges]

Bonjour
J'ai un appli en cours de finalisation et je suis amené à faire des stop / undéploy / déploy plusieurs fois d'afilé avec connexion via un pool à une bdd mysql. Après 5 ou 6 redéploiement, Tomcat reste muet et se fige sans que la charge processeur ne s'affole. Après un redémarrage de Tomcat tout redevient normal puis le pb réapparait.
Les données d'init du pool sont enregistrées dans un fichier properties renseigné via une servlet après le déploiement. Donc au lancement la connexion capote puis après appel de la jsp la connexion est ok.

J'ai testé x stop / undéploy / déploy lancement appli sans connexion à la bdd et tomcat reste ok.
J'ai testé x stop / start / lancement appli avec connexion à la bdd et tomcat reste ok.
J'ai testé x stop / undéploy / déploy lancement appli avec fichier properties prérenseigné et connexion à la bdd et tomcat reste ok.

Donc il semberai que ça vient des erreurs de connexion à un bdd inconnue remontées avant que le fichier properties ne soit correctement renseigné. Cette solution adoptée ne pouvant pas être reconsidérée.

Avez vous une idée.
Merci

[tchize_]

t'as vérifié que ton appli fait bien un close() sur toutes ses connections db lors de l'arrêt. Je dirais, à vue de nez, que t'arrive à cours de connection a force de les jeter sauvagement sans faire de close()

[Mengué georges]

Oui oui, je me suis fait avoir au début.
Je prends une connexion pout ttes les rqtes select qui est fermée à la fin de la servlet et les rqtes update et delete sont traitées par un méthode inclue dans le pool du type getexecute(String sql)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public static boolean getExecute(String sql)
    	{boolean ok = false;
    	 Connection conn = getConnection();
    	 try{conn.setAutoCommit(false);
    	 	conn.createStatement().executeUpdate(sql);
    	 	conn.commit();
    	 	conn.setAutoCommit(true);
    	 	conn.close();
    	 	ok = true;
    	 }catch(final SQLException e){//e.printStackTrace();
    	 							  StackTraceElement[] test = Thread.currentThread().getStackTrace();
    	 							  index.GestMat.trace += test[2].toString()+"<br />1 - "+sql+"<br /><br />";}
    	 finally{try{conn.commit();conn.setAutoCommit(true);conn.close();}
	 	   catch(final SQLException e){}}
 
    	 return(ok);
    	}

[Mengué georges]

Petite indication supplémentaire: ce sont les fct de tomcat qui deviennent inopérantes, si on j'appelle la page web j'ai:
La ressource demandée (/demo/gest) n'est pas disponible lorsque le pb survient lors d'un déploiement ou le undéploy est inopérant suite à un stop

[tchize_]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
finally{
  try{
    conn.commit();
    conn.setAutoCommit(true);
    conn.close();
  } catch(final SQLException e){}
}

alors çà, c'est très mauvais. Non seulement tu droppe silencieusement SQLException, donc tu saura jamais si commit() fait un erreur, mais en plus si commit fait un erreur, tu ne fait pas le close() -> connection perdue.

Ceci dit, vu ta description, je ne m'inquiéterais pas pour les requetes que fait la servlet à la demande du user, mais plutot pour les requête qu'elle fait au démarrage.

Aussi, y-a-til des messages d'erreurs dans catalina.out. Tu mentionne un "ressource non disponible", ceci se produit lorsqu'une servlet ou la webapp a fait remonter une exception lors de l'initialisation de la webapp. Hors cette erreur doit être présente soit dans catalina.out, soit dans les autres logs de tomcat.

[Mengué georges]

Donc je viens de refaire la manip. Après 4 déploiements, blocage et pas d'erreur ci-dessous le log catalina:

6 juin 2008 20:59:01 org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Apache Software Foundation\Tomcat 5.5\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
6 juin 2008 20:59:01 org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initialisation de Coyote HTTP/1.1 sur http-8080
6 juin 2008 20:59:01 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1078 ms
6 juin 2008 20:59:01 org.apache.catalina.core.StandardService start
INFO: Démarrage du service Catalina
6 juin 2008 20:59:01 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.20
6 juin 2008 20:59:01 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
6 juin 2008 20:59:02 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive demo1018.war de l'application web
6 juin 2008 20:59:02 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive maquettes.war de l'application web
6 juin 2008 20:59:03 org.apache.coyote.http11.Http11BaseProtocol start
INFO: Démarrage de Coyote HTTP/1.1 sur http-8080
6 juin 2008 20:59:04 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
6 juin 2008 20:59:04 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/93 config=null
6 juin 2008 20:59:04 org.apache.catalina.storeconfig.StoreLoader load
INFO: Find registry server-registry.xml at classpath resource
6 juin 2008 20:59:04 org.apache.catalina.startup.Catalina start
INFO: Server startup in 2688 ms
6 juin 2008 20:59:19 org.apache.catalina.core.StandardContext stop
INFO: Le conteneur org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/demo1018] n'a pas été démarré
6 juin 2008 20:59:19 org.apache.catalina.startup.HostConfig checkResources
INFO: Repli (undeploy) de l'application web ayant pour chemin de contexte /demo1018
6 juin 2008 20:59:28 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive demo1018.war de l'application web
6 juin 2008 21:00:10 org.apache.catalina.core.StandardContext stop
INFO: Le conteneur org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/demo1018] n'a pas été démarré
6 juin 2008 21:00:10 org.apache.catalina.startup.HostConfig checkResources
INFO: Repli (undeploy) de l'application web ayant pour chemin de contexte /demo1018
6 juin 2008 21:00:20 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive demo1018.war de l'application web
6 juin 2008 21:00:52 org.apache.catalina.core.StandardContext stop
INFO: Le conteneur org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/demo1018] n'a pas été démarré
6 juin 2008 21:00:52 org.apache.catalina.startup.HostConfig checkResources
INFO: Repli (undeploy) de l'application web ayant pour chemin de contexte /demo1018
6 juin 2008 21:01:03 org.apache.catalina.startup.HostConfig deployWAR
INFO: Déploiement de l'archive demo1018.war de l'application web
6 juin 2008 21:01:39 org.apache.catalina.core.StandardContext stop
INFO: Le conteneur org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/demo1018] n'a pas été démarré
6 juin 2008 21:01:39 org.apache.catalina.startup.HostConfig checkResources
INFO: Repli (undeploy) de l'application web ayant pour chemin de contexte /demo1018

Hormis le fait que l'appli ne peut pas se connecter à la bdd à chaque premier lancement (avant que le fichier properties ne soit initialisé), je n'ai pas d'autre remontée.
Le pb n'apparait qu'après n cycle de connexion ratée / connexion réussie
Pour ce qui est du finally je vais supprimer le conn.commit() qui il est vrai n'a rien à y faire puisque le retour de ok m'informe de l'erreur, ce qui permettra de clore la connexion.

[Mengué georges]

En allant voir dans le webapps de tomcat je viens de me rendre compte que le rep de l'appli venant d'être déployé est vide ?

[tchize_]

ET le .war? quelle taille? 0 octets?

[Mengué georges]

Le war fait 8Mo mais je viens de me rendre compte aussi que lors d'un undeploy le fichier war enregistré via le manager est supprimé mais pas le rep du context qui est par contre vidé de son contenu sauf du fichier prperties qui ne peut être supprimé car utilisé par un autre processus ???

[tchize_]

ha, je vois, windows hein

y a ce problème qui peut se produire

* tomcat + webapp X (version 1) ouvre le fichier properties (jusque là normal) et le référence indirectement depuis un champ de classe de la webapp (souvent, çà proviens d'un singleton)
* ensuite undeploy, mais un leak empeche le garbage collect du webappclassloader
* arrivée de la nouvelle webapp, elle ne sais pas exploser le .war car la place est toujours occupée par le classloader précédent et, sous windows, le locking est systématique des ressource, donc pas d'effacement possible
* clash!


Y a une option dans tomcat pour contourner ce locking (à configurer dans server.xml, voir la doc tomcat), çà pourrait t'aider. Renseigne toi aussi sur le phénomène de leak liée au classloader j2EE, c'est du à des erreur subtiles dans ta webapp (souvent, non nettoyage d'un Threadlocal, résultat le HTTPThread maintient un référence vers un objet de ta webapp qui elle meme maintient une référence vers son webappclassloader qui lui même maintient des références vers toutes les classes de WEB-INF/ qui elles même maintienent cerains ressource.

[Mengué georges]

Merci pour ta réponse mais j'ai aussi semble-t-il le même pb sur le serveur de l'entreprise qui est sous linux mais qui n'est pas de mon ressort.
Donc je reviendrai sur ce sujet plus tard après avoir lu la prose en question.

[Mengué georges]

Donc pour terminer suite à la piste donnée, j'ai modifier l'accès au fichier properties en remplaçant la méthode loadProperties(fileDbcpProperties) par:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
final Properties props = new Properties();
FileInputStream fis = null;
try {
	fis = new FileInputStream(fileDbcpProperties);
	myProps.load(fis);
	fis.close();
	fileDbcp.displayProperties(myProps);	
} catch (FileNotFoundException e) {e.printStackTrace();}
  catch (IOException e) {e.printStackTrace();}
  catch (NullPointerException e) {e.printStackTrace();}

qui me libère la ressource et tout est rentré dans l'ordre.