Version imprimable
Bonjour,
J'utilise un client telnet développé en java swing. Ce client swing, sur certains poste client (déployé avec java web start) fige, l'écran bloque parfois, impossible de continuer, l'application doit être fermer pui relancée. Le problème ne se produit pas sur toutes les machines. Y a t'il des probleme d'incompatibilité avec certaines cartes grpahiques, carte reseau ? ... Vos idées sont les bienvenues.
Pour info le client telnet est : http://javatelnet.org/space/start
Johann
Je parierais sur une mauvaise utilisation de Swing (EDT) lors des appels (longs) de primitives sur le réseau :)Citation:
Envoyé par jfpons
Les appels se font bien dans un thread séparé, n'est-ce pas?
==> sinon, j'ai gagné
+1 très peu probable que se soit la carte graphique ou la carte réseau.
N'ayant que survolé ( de très haut java web start ), serait-il possible que cela vienne d'une différence de JVM sur les différents postes ?
Je ne sais pas si c'est une mauvaise utilisation de SWING mais en tout cas avec java JRE 1.6 plus aucun problème alors que sur certain poste l'écran bloquait de temps en temps sans meme pouvoir sélectionner avec la souris les caractères présents sur l'écran telnet affiché !
En résumé, j'ai rien touché, j'ai mis sur les clients à problème JRE 1.6 et ça tourne. JRE 1.6 gère mieux la mémoire ?
J'ai passé beaucoup de temps à essayer de comprendre mais lorsque qu'il n'y a pas d'erreur visible c'est délicat.
Je n'aime pas trop laisser les problèmes comme ça, je vais regarder du coté de l'utilisation de swing mais c'est une vaste investigation et les projets doivent avancer !
Quel rapport avec la gestion de la mémoire ? La "correction" du problème pourrait venir du meilleur double-buffering introduit dans Java SE 6. Je te conseille vivement de corriger ce problème car il se peut que Java SE 6 ne l'ait pas vraiment résolu (si cela vient d'un interblocage de threads par exemple).
Romain, as tu un conseil pour identifier ce problème ? ( Pour info sur les postes qui posaient problème je n'ai plus jamais eu le problème). Le blocage était très alléatoire. Deux postes sur java 1.5 update 10, l'un bloque l'autre non...
Une info complémentaire : ma JFRAME principale contient un menu swing et le module telnet est un COMPONENT. Lors du blocage, le menu reste accessible contrairement au "rendu caractères" du module telnet qui reste figé et impossible à sélectionner pour un éventuel copier/coller les caractères présents à l'écran.
Si le problème est aléatoire, c'est sûrement un interblocage entre threads. Je te conseille d'utiliser un profiler, comme celui de NetBeans, pour regarder le comportement des threads et voir s'il s'agit bien d'un problème de synchronisation.
interblocage de thread...je crainds le pire ! :cry:
Je dois arriver à reproduire ce problème sur une machine avec netbeans et au moment où ça fige cet "interblocage" sera visible ? C'est délicat.
Question intermédaire : Peut il y avoir un rapport avec la taille de l'archive jar mise en cache sur le pc local ?
Merci pour votre aide.
C'est bien le problème avec la programmation multi-thread, le debug peut être assez casse-tête. Note que le profiler de NetBeans peut se connecter à un processus qui n'a pas été lancé par NetBeans. Ça marche même à travers le réseau.
Quant à la taille du JAR en cache je nme vois pas pourquoi ça poserait un problème ?!
Pour finir sur le sujet et commencer mes recherches deux petites questions :
1/ Un deadlock peut peut facilement venir causer problème dans une application,
c'est courant ?
2/ Même si il n'est plus présent à ce jour il peut revenir ? ;)
Les deadlocks sont relativement courants quand on ne fait pas attention au code qu'on écrit pour du multi-thread ;-)
Et il peut en effet "revenir". Il n'a pas vraiment disparu. C'est tout le problème des deadlocks, c'est que beaucoup peuvent survenir dans des conditions très spécifiques, souvent dues au hasard. Si tu ne le vois plus sur tes machines il y a fort à parier qu'un utilisateur le verra un jour.