Discussion :

[Balbuzard]

Bonjour,

Je travaille sur un projet où il y a exportation de fichiers d'un format dans un autre.

Les méthodes d'exportation ne me sont pas accessibles, et il arrive que selon les fichiers à exporter, l'application "plante" à cause de ces méthodes : l'exportation prend un temps infini et ne renvoie rien.

Je voudrait savoir s'il existe un façon de faire qui puisse prévenir l'utilisateur du bug, voire, mieux, de lui permettre de stopper la méthode qui plante.

J'ai pensé à mettre les méthodes à risque dans des Thread à part, et dans le Thread principal, écrire une méthode permettant de stopper le Thread à part.

Seulement, la plupart des méthodes permettant de mettre en pause ou de stopper les Thread partent du principe que le Thread vérifie périodiquement une variable (que le Thread principal transforme lors de l'arret). Si ma méthode plante, tout se passe comme si le Thread à stopper entrait dans une boucle infinie, (genre while(true) {}) et ne pourrait plus vérifier l'état de cette variable.

Quelqu'un aurait-il une idée pour résoudre mon problème?

Je vous remercie vivement de vos aides et conseils ;-)

EDIT: J'ai pensé à un Timer qui vérifie périodiquement si le Thread à part et toujours alive, et si au bout d'un long moment, c'est toujours le cas, afficher un message pour avertir l'utilisateur. Mais je ne vois toujours pas comment stopper le Thread à part et commencer une nouvelle tâche...

[aperrin]

http://www.opensymphony.com/quartz/

[ndp]

salut,

est-ce que tu peux chercher l'origine du bug?
exp: tue le process java, recupere le thread dump.

[Balbuzard]

Salut,

Je comprends pas ce que tu veux dire par "tue le process java" "récupère le Thread dump", je suis relativement novice en programmation :-S

Pourrais-tu être plus explicite?

Merci :-)

[ndp]

l'idee est la suivante: ton programme bloque et il faut determiner ou est-ce qu'il bloque.

il bloque parce qu'un thread bloque (peut etre en attente d'un lock,d'une operation d'I/O...)
Pour savoir ca, tu peux examiner l'etat de l'ensemble des threads a un moment donne (stack trace,etat vis a vis des verrous) ---> c'est ca le thread dump

Une facon de recuperer le thread dump, c'est d'envoyer un signal au processus java qui tourne, pour l'arreter. Et avant de s'arreter, il y a des chances qu'il produise un thread dump (ie: l'etat de tous les threads au moment ou il s'est arrete). En gros, tu tues le processus java que tu as demarrer pour lancer ton appli

[Balbuzard]

D'accord.

Mais le problème est que je ne peux pas toucher aux méthodes d'exportation, sinon, j'aurais pu me débrouiller de mettre une condition quelque part.

Il faut donc que je fasse avec le fait que le Thread qui gouverne l'action d'exportation peut planter.

Ce que je pense faire au final, c'est de mettre la méthode à risque dans un Thread que je déclare Daemon (il s'arrêtera lorsqu'il aura exporter mes fichiers ou bien s'il plante à la fermeture de l'application) et si le Thread reste en vie trop longtemps (temps mesuré avec un Timer), alors il en lance un autre qui prend le relai.

Voilà!!!

Il me reste plus qu'à programmer tout ça :-S

Merci en tout cas à tous les deux pour vos conseils :-)

[ndp]

moi le conseil que je te donne, c'est de d'abord determiner la raison du blocage, avant toute chose.

Surtout avant de te lancer dans des threads daemons et cie

[Balbuzard]

C'est vrai que ce serait plus prudent.

Je pense que le problème vient que pour certains fichiers xml ne comportent pas les balises que cherche à lire les documents xsl associés. Je ne peux pas en être totalement sûr, car les méthodes en question ne me sont pas accessible.

Bon, je vais quand même me lancer, de toute façon, c'est ça ou rester avec una application qui risque de planter...

Merci pour tes conseils :-)

[tchize_]

quelques indices:

d'abord, comme mentionné, obtenir un Thread dump. Le plus facile, t'attends que çà "bloque", et, si t'es sour linux/unix, tu tappe dans une autre console "kill -3 <numero du pid java>", pour récupérer le numéro de pid, un"ps" est utile. Si t'es sous windows, si ma mémoire et bonne, tu fait CTRL-Z dans la console à t'as démarré java. C'est un processus de la jvm qui va t'afficher tous les threads de ton application et à quel endroit ils sont.

Deuxième chose: tu mentionne de la gestion de xml, les processus xml, si il font de la validation et si ils référencent un xsd, vont tenter de la télécharger sur internet si ils ne l'ont pas en local. Si ton process est derrière un firewall, il attends peut etre 3 plombes que le serveur daigne lui répondre. Le thread dump aidera à identifer ce genre de problème.

Si tu n'arrive pas à lire le thread-dump, n'hésite pas à paster ici le Thread qui te concerne, on t'aidera à le lire


Edit: un sniff des tentative du réseau, avec des outils comme wireshark, peut pafrois aussi s'avérer intéressant.

[lashemale]

Bonjour,

j'ai fait aussi un kill -3 sur un process java (jvm d'un serveur d'applis) mais je n'arrive pas à retrouver les infos liées à ce thread dump
Sortie stdout standard ? fichier de log de mon serveur d'appli ? fichier à part ?
autre fichier.
Où puis-je récupérer ces infos ?
Merci

[tchize_]

sur stdout ou stderr, je suis pas sur. Si t'es sous tomcat çà finira donc dans logs/catalina.out