Discussion :

[LGnord]

Salut,


J'ai un programme qui fait de gros calculs et donc il consomme beaucoup de temps.

Parfois, j'ai envie d’interrompre mon programme avant la fin. Mais j'ai envie d'avoir quelques information sur ce qui s'est passé. Par exemple, j'aimerai connaitre la quantité de donner qui ont été traitées.

Pour cela, quand je suis sous Eclipse, je clique sur le 'bouton rouge'. Dans les autres contextes, je fait un 'Ctl C'.

Comment puis-je savoir dans mon code qu'une telle action a eu lieu? Y-a-t-il un lien avec l'InterruptedException?

Merci de votre aide.

[therwald]

L'InterruptedException est un moyen de notifier à une thread suspendue (ex: on a appelé Thread.sleep()) qu'on a changé quelque chose pendant qu'elle "dormait". Cette exception est déclenchée par l'appel de la méthode Thread.interrupt() par une autre thread. Pas de lien donc avec le kill sauvage du process.
Les shutdown hooks de la JVM permettent peut-être de faire quelque chose, mais sans garantie...

Pour moi, le meilleur moyen de savoir où en était ton programme reste d'avoir des logs bien pensés (sans garantie que tu aies le dernier état juste avant le kill, tu auras l'état au moment du dernier appel de log en date), et/où si tu as des résultats intermédiaires enregistrés d'analyser l'état des données.

[thelvin]

Les shutdown hooks de la JVM permettent peut-être de faire quelque chose, mais sans garantie...

On ne peut rien contre un vrai gros kill sauvage, c'est sûr... Et apparemment c'est ce que fait le bouton rouge d'Eclipse.

Mais pour les trucs comme le ctrl+C et autre kill simple, ça peut être repéré (mais pas annulé) par Runtime.getRuntime().addShutdownHook(hook);

[therwald]

Mais pour les trucs comme le ctrl+C et autre kill simple, ça peut être repéré (mais pas annulé) par Runtime.getRuntime().addShutdownHook(hook);

Du coup ça doit pouvoir être utilisé pur répondre à la question: préparer un aprçu de l'état du programme au moment de l'interruption...
Comment la JVM gère-t-elle les hook "rebelles"? Time-out kill? Ca dépend peut-être de la JVM en question?
EDIT: ceci dit je me demande si ça vaut le coup de faire aussi compliqué pour ce que de simples logs bien choisis permettraient de faire avec une assez bonne précision...

[therwald]

Après avoir visité mon ami google, les shutdownhooks:
1) ne garantissent rien
2) globalement ont intérêt à travailler plutôt vite
3) doivent être écrits très précautionneusement car la période de fermeture d'une JVM n'est pas forcément un moment où l'environnement est stable

cf ici: http://download.oracle.com/javase/1....lang.Thread%29

Globalement, je pense que plutôt que de chercher à détecter la fermeture et vite essayer de préparer un résumé des traitements & co, LGNord devrait compter sur des logs qui retracent au fur et à mesure l'avancement. Il suffit de trouver le bon compromis entre précision des indication et consommation de ressources (surtout espace disque, d'ailleurs) par les logs.

[LGnord]

Super. Merci beaucoup pour vos réponses.

Je ne me suis pas encore lancé dans les logs car j'ai une crainte: celui de dimuner les performances de mon application.

Par exemple, je kill mon application aprés 5 minutes. Mon log m'indique que 3% de mes données ont été traitées. Que conclure de cette information? Peut-être que 90% du temps a été passé dans le code qui gére le log.

Comme vous l'avez bien dit, j'ai besoin d'un system de logs bien pensés...

[therwald]

Super. Merci beaucoup pour vos réponses.

Je ne me suis pas encore lancé dans les logs car j'ai une crainte: celui de dimuner les performances de mon application.

Par exemple, je kill mon application aprés 5 minutes. Mon log m'indique que 3% de mes données ont été traitées. Que conclure de cette information? Peut-être que 90% du temps a été passé dans le code qui gére le log.

Comme vous l'avez bien dit, j'ai besoin d'un system de logs bien pensés...

La réponse s'appelle log4j ou son successeur logback
Ils sontoptimises pour.

[LGnord]

Je vais aller voir.

Encore merci pour votre aide.

[SamSer]

Tu peux aussi checker AOP (c'est un paradigme).

[therwald]

Avec un bémol: l'AOP est juste une manière de gérer automatiquement où on ajoute certaines comportements transversaux, donc ne répond à mon sens pas directement à la question. Perso je trouve l'AOP plus adapté à des projets de style grands projets industriels très normés où on a des politiques à faire adopter de manière générale. Attention aussi au style d'AOP adopté quand on fait du calcul intensif: l'AOP spring sans tissage, avec ses proxy, génère des indirections dans les appels de méthode qui ne sont pas forcément perf friendly...sans parler du coût en complexité d'ajouter spring à une appli juste pour ça...l'AOP tissée, en revanche, préserve les perfs mais complexifie le build...et là on en revient au type de projet, qui serait plus ciblé projet industriel normé...

[SamSer]

Je trouve ça plus propre personnellement. Et puis, j'avoue que je n'ai pas pris le temps de tester les perf (car je n'ai jamais eu de problème de perf en utilisant ce procédé).

Je proposais ça en plus de ce que tu avais dis. Histoire que le concerné ne se trouve pas avec une seule solution.

[LGnord]

Merci SamSer.

Je suis effectivement curieux. De ce fait je suis pret à explorer toutes les proposition. Par contre, une rapide recherche sur AOP me fait craindre que le cout de mise en œuvre soit supérieur au gain de que je vais avoir.

Par ailleurs, l'idée des logs me plait bien car elle va me permettre de résoudre d'autres problèmes. Ils sont en bas de ma TODO liste mais je vais faire d'une pierre plusieurs coups.

[therwald]

SamSer a raison sur un point: AOP permet de résoudre élégament certains problèmes. Pour résumer, il marche très bien sur tous les problèmes du genre:
"partout où je fais cette action, je veux appliquer ce code" quand l'action en question (généralement parce que la préoccupation est technique et non fonctionnelle) est répartie un peu partout sur des parties de ton modèle qui ne sont pas forcément reliées fonctionnellement. Ca permet de ne pas polluer ton code et/ou ton modèle fonctionnel par des considérations plutôt techniques. Comme tu le souligne, le bémol c'est la complexité que ça ajoute. Ca peut aussi rendre le code plus difficile à comprendre, puisque le produit final fait des choses qui ne figurent pas noir sur blanc dans le code ciblé. Comme beaucoup d'outils puissants, ça fait des merveilles quand on s'en sert bien, et des catas quand on en abuse...

[LGnord]

Dans les exemples d'utilisation de l'AOP, je trouve souvent:
- information pendant l'exécution du logiciel (trace) ;

trace, log c'est quand même plus ou moins la même chose... L'idée n'est peut pas à jeter si vite...

[therwald]

L'idée n'est en soi pas à jeter: en effet le log est un cas d'utilisation classique pour AOP. Dans de grosses applis où modifier une politique de log peut mener à modifier très nombreux points de code ça peut même être fondamental pour éviter de gaspiller de nombreuses heures à faire la même modif en x points du code, sans parler du risque d'oublis et d'erreurs. Ca peut même permettre de faire certaines choses très dures (voir impossibles) sans (je me rappelle encore du débuggage d'une fuite de connections bases de données gràce à un AOP bien senti sur les méthodes open/close des API JDBC...).
Je soulignais juste que ça a un coût qu'il faut payer en connaissance de cause en terme de complexité d'appli / lisibilité du code. Comme disait la pub: sans maitrise la puissance n'est rien...
Mais j'utilise régulièrement un forme ou une autre d'AOP et c'est magique sur certains problème...