Discussion :

[Gaspard22]

Bonjour,

J'ai un comportement que je n'arrive pas à comprendre et auquel trouver une solution sur un XP pro, il se peut que se soit le mauvais endroit pour raconter mon problème, mais peut être que ça peut vous parler tout de même.


Contexte : une appli, avec une interface graphique en SWT , tournant sur plusieurs plateformes différentes, fige sur un seul poste sous XP.

l'appli tourne, mais dès qu'il s'agit de générer une fenêtre ou un menu, celui ci n'affiche que la cadre et se fige en prenant 50 % du CPU.
Dans mon log, je ne génère aucune erreur. Aucune erreur dans le système.

Le SP3 est mis à jour, la JRE installée est la dernière. Qu'est ce qui pourrais me faire figer les ihm ? quelqu'un pourrait m'aider, ou m'indiquer quoi regarder....

merci d'avance

[joel.drigo]

Salut,

Tu es sous quelle version de Java ? De SWT ?

[Gaspard22]

java sur poste : jre 1.7 update 55 sur code : 1.6.0_30

SWT : version 3.740

La plateforme concernée est un XP pro avec SP3 et toutes les updates.

La bizarrerie, vient que d'autres XP avec à peu près cette config marchent sans pb.

[joel.drigo]

Déjà, tu peux utiliser la jvisualvm (si tu as accès au poste où se passe le gel) pour faire un thread dump et voir éventuellement s'il y a un deadlock visible.

[Gaspard22]

merci, je vais essayer ça

[Gaspard22]

j'ai effectué un thread et heap dump, je n'ai rien vu de choquant à part le CPU faire un bon de 0 à 50 % lors de l'utilisation d'une fenêtre.

Après n'ayant pas l'habitude de faire du profiling, je ne sais pas vraiment ou regarder. J'ai sauvegardé plusieurs dump , afin de pouvoir les "analyser".

Y a t il un article quelque part qui parle de l'analyse des résultats ?

merci

[joel.drigo]

A priori, si ça fige dans (ou ça ralenti) dans l'affichage, c'est le thread graphique qu'il faut regarder (en général le thread main en SWT, mais sinon celui où a été créé l'instance de Display). Si tu as fait ton dump pendant le ralentissement, tu devrais pouvoir voir un peu près ce qu'il était en train de faire.

Postes-les en pièce jointe, que je jette un coup d'œil.

Sinon, je ne sais pas s'il y a des articles sur l'analyse de résultats de profilage. Personnellement, quand je suis confronté à ce genre de problématique, si le thread dump ne m'aide pas, j'ai plutôt tendance à utiliser le mode debug (enfin, si l'exploitation n'a pas décidé de changer le poste incriminé, ce qu'il se passe dans 99% des cas).

[Gaspard22]

mon zip etant trop lourd pour l'interface du site je te donne le lien suivant

https://drive.google.com/file/d/0BxX...it?usp=sharing

merci de l'aide

[joel.drigo]

mon zip etant trop lourd pour l'interface du site je te donne le lien suivant

https://drive.google.com/file/d/0BxX...it?usp=sharing

merci de l'aide

Trop lourd ? Tu as combien de threads et combien de dumps ?

[Gaspard22]

le thread ne pese que 17 kilo, c'est le heap dump qui lui pèse 7 mo

[joel.drigo]

Il y a quel code dans la méthode run() de com.cwfse.rx.GestionGlobPar : je trouve étrange l'invocation d'un syncExec dans une méthode invoquée par le thread SWT.

Je ne vois rien de spécial, à part peut être beaucoup de thread jetty, mais qui sont tous dormant (bon je ne connais pas le fonctionnement de jetty, donc je ne peux pas trop interprété les stack traces que je vois). Peut être regarder du côté de la lecture de fichier aussi (en ajoutant des chronos en log, pour voir si ça pèche pas de ce côté).

[Gaspard22]

l'invocation d'un syncExec dans une méthode invoquée par le thread SWT est obligatoire lorsque le code doit être portable sous macosx. (Enfin c'est comme ça que j'ai réussi à le faire marcher aussi sous mac)

Pour ce qui est de jetty, mon module discute en websocket avec un autre module, mais qui n'était pas connecté lors du dump.

bref, je te remercie d'avoir regardé, le mystère restera entier. L'utilisateur concerné devra changer de pc ou abandonner notre solution malheureusement.

Bonne journée

[joel.drigo]

l'invocation d'un syncExec dans une méthode invoquée par le thread SWT est obligatoire lorsque le code doit être portable sous macosx. (Enfin c'est comme ça que j'ai réussi à le faire marcher aussi sous mac)

Oui, si le code est invoqué depuis un thread non SWT, mais pas si le thread d'invocation est celui de SWT, comme cela semble l'être. Si effectivement ce code peut être invoqué depuis différents threads, je procède personnellement en testant d'abord si je suis ou pas sur le thread SWT, et si je suis sur MACOSX (parce que pour le coup, si je le fais pas, j'ai des deadlocks : en tout cas, comme j'ai ce cas souvent en invocation depuis le thread de SWING, j'ai des interblocages SWT/SWING).

bref, je te remercie d'avoir regardé, le mystère restera entier. L'utilisateur concerné devra changer de pc ou abandonner notre solution malheureusement.

D'un autre côté, votre client a plutôt intérêt à migrer vers une version plus récente de Windows, vu que XP n'est plus maintenu par Microsoft (gros risques).

Bonne journée

Merci, toi de même.