Discussion :

[if_zen]

Bonjour,

J'ai récupéré un thread dump (à l'aide de jConsole) de mon appli qui est bloquée chez un client. Le thread EDT semble complètement bloqué (le contenu de la fenêtre n'est pas redessiné). Par contre, Le dump du thread AWT-EventQueue ne veut pas s'afficher dans jConsole.

J'ai fait le tour des autres threads, et je remarque que l'un d'entre eux est bloqué sur une lecture de flux (socketRead0, statut RUNNABLE). Ce n'est pas la première fois que je vois l'application bloquée sur ce genre d'instruction, mais je ne comprends pas ce que cela signifie.

J'ai commencé par penser qu'il pouvait s'agir d'un problème de firewall (il s'agit d'un flux réseau ; l'adresse pointée est une JSP sur un serveur) mais cela ne semble pas venir de là.

Ce plantage est apparu alors que l'application n'était pas utilisée (réduite). Par contre une petite coupure réseau n'est pas a exclure.

Pouvez-vous m'éclairer ? Que me conseillez-vous ?
Merci beaucoup.

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
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Name: Dom-enregistreur
State: BLOCKED on fr.ste.com.sessions.Session@354093 owned by: Actualiseur Session
Total blocked: 9  Total waited: 170*780
 
Stack trace: 
 fr.ste.com.dataObject.DataObject.flush(DataObject.java:744)
fr.ste.com.dataObject.Manager.flush(Manager.java:74)
fr.ste.com.dataObject.Manager$1.run(Manager.java:48)
fr.ste.com.Timer$ThisTask.run(Timer.java:36)
java.util.TimerThread.mainLoop(Unknown Source)
java.util.TimerThread.run(Unknown Source)
 
---
---
---
 
Name: Actualiseur Session
State: RUNNABLE
Total blocked: 6  Total waited: 861
 
Stack trace: 
 java.net.SocketInputStream.socketRead0(Native hod)
java.net.SocketInputStream.read(Unknown Source)
java.io.BufferedInputStream.fill(Unknown Source)
java.io.BufferedInputStream.read1(Unknown Source)
java.io.BufferedInputStream.read(Unknown Source)
   - locked java.io.BufferedInputStream@956ce1
sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
   - locked sun.net.www.protocol.http.HttpURLConnection@1f511c
fr.ste.com.files.File.getInputStream(File.java:953)
fr.ste.com.Response.getResultString(Response.java:66)
fr.ste.com.ManipData.update(ManipData.java:610)
fr.ste.com.DataObjectWriter.update(DataObjectWriter.java:338)
   - locked fr.ste.com.DataObjectWriter@18b2ad5
fr.ste.com.DataObjectWriter.flush(DataObjectWriter.java:360)
   - locked fr.ste.com.DataObjectWriter@18b2ad5
fr.ste.com.dataObject.DataObject.flush(DataObject.java:772)
   - locked fr.ste.com.sessions.Session@354093
fr.ste.com.dataObject.DataObject$1.call(DataObject.java:44)
fr.ste.com.ihm.connexion.Connexion$TaskInError.get(Connexion.java:34)
fr.ste.com.dataObject.DataObject.sauvegarder(DataObject.java:61)
fr.ste.com.Timer$ThisTask.run(Timer.java:36)
java.util.TimerThread.mainLoop(Unknown Source)
java.util.TimerThread.run(Unknown Source)

[dinobogan]

Peut-être un flux réseau très lent ?
Sans code, difficile d'en dire plus.
Si tu simules une pause gigantesque à l'endroit ou la socket semble lit, reproduis-tu le problème graphique ?

[tchize_]

même avec un réseau rapide, t'aura beaucoup de socket.read en attente dans tes thread, et c'est normal. Ca signifie juste que le buffer de la socket est en attente de la suite de l'émetteur. Il peut être vidé pour tout un tas de raison, la principale étant que tu consomme la socket plus vite que ton émetteur ne la remplis. si t'es sur une bonne machine et que tu fais des traitement simple, c'est tout à fait normal.

Personellement, pour avoir un thread dump complet, j'y vais à l'ancienne:

kill -3 sous unix (ça n'affecte pas la jvm)
ou
ctrl-z en interactif sous windows (plus complexe à réaliser comme opération)

et le thread dump atteris joyeusement dans le stdout


Si l'EDT est bloqué, pas de mystère: soit t'attends un truc qui n'avance vraiment pas vite, soit t'as un deadlock (le threaddump à l'ancienne devrais indiquer les deadlocks potentiels)

[if_zen]

Bonjour,

Tout d'abord merci d'avoir apporté vos réponses.
En fait, je ne pense pas qu'il soit normal que mon flux reste ouvert. Il s'agit d'un appel à une JSP qui renvoie bêtement un texte en retour.
Pour le Thread dump j'ai utilisé jConsole car l'application était lancée en Java Web Start.
On voyait l'EDT bloqué, mais par contre impossible de récupérer le dump du thread, c'est bizarre. La prochaine fois j'essaierai une autre méthode pour le récupérer.

Ma classe Actualiseur est un Timer qui s'exécute toutes les 10 secondes. Elle est bloquée lors de l'appel à un java.net.HttpURLConnection dans la méthode getInputStream :

Code :

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

1
2
3
4
5
6
7
8
9
java.net.HttpURLConnection httpURLConnection = new sun.net.www.protocol.http.HttpURLConnection(urlToConnect, null);
httpURLConnection.setRequestMethod("POST");
httpURLConnection.setDoOutput(true);	
httpURLConnection.setDoInput(true);
 
// Envoi des données par POST
MyStream.io(stringReader, new OutputStreamWriter(httpURLConnection.getOutputStream()));
// blocage ici :
retour = httpURLConnection.getInputStream();

[if_zen]

Bonjour,

J'ai de la chance, ça a recommencé...
J'ai réussi à récupérer le dump EDT avec jstack :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
"AWT-EventQueue-0" prio=6 tid=0x47776400 nid=0xd74 in Object.wait() [0x454ff000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:485)
	at java.awt.EventQueue.getNextEvent(Unknown Source)
	- locked <0x129e0950> (a java.awt.EventQueue)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

Je n'ai pas de suspicions vers un thread "bloqué" sur socketRead0 cette fois, mais le problème est apparu de la même façon : en ne faisant rien... Le contenu de ma fenêtre ne s'affiche plus (seule la barre de titre s'affiche, l'appli réagit quand je clique sur la croix pour fermer). On dirait que le thread AWT-EventQueue est passé en mode zombie
Un dump complet est accessible ici.

Je ne vois absolument rien d'anormal

[dinobogan]

Utiliserais-tu "stop" sur un thread ?

[if_zen]

@dinobogan : absolument pas !

[tchize_]

Le thread EDT tourne de manière normale. Donc on s'oriente plus vers un bug d'affichage qu'un blocage de l'application.

Les questions à se poser:
1) toujours sur la même machine?
2) quel OS (tous, un seul bien particulier?)
3) reproductibilité par une série d'actions de l'utilisateur?


Je ne vois que trois possibilités par mon expérience
1) pour une raison x ou y tu a vidé le contentPane de la fenetre, fait un setVisible(false) dessus ou autre chose similaire.
2) Bug d'affichage de la librairie AWT, ça se produisait dans le passé sous certaines distribution linux avec compiz, des fenetres devenaient blanches. Essayer de mettre à jour la JVM.
3) Tu manipule des composants de l'interface graphique en dehors de l'EDT. Le look and feel "substance" est à essayer, il est très rigoureux à ce sujet et t'avertira rapidement de ce genre de chose en lancant préventivement une exception.

[if_zen]

Bonsoir Tchize,

Merci pour ces suggestions.

Pour répondre aux différentes questions dont tu fais allusion, le bug dont je parle est déjà arrivé sur d'autres postes, mais n'est pour ainsi dire pas vraiment reproductible. Je tourne sous XP, je n'ai pas souvenir que le souci ait eu lieu sur d'autres OS (on installe des mac aussi, mais pas de linux).

Ce n'est pas, je pense, un problème de removeAll ou un truc du genre de mon contentPane (ou alors java s'est pris des permissions sans les demander ). Cela touche la fenêtre principale de l'application, et a lieu après un certain temps d'inactivité a priori. Lorsque je passe une autre fenêtre qui n'a rien à voir par dessus avec la souris, le contenu de la fenêtre qui survole reste dessiné sur la fenêtre de mon application.

Les points 1 et 2 sont donc à mon avis à écarter.
Pour le point 3, ça pourrait être intéressant d'utiliser substance au moins pour voir si je n'ai pas des problèmes de threads.

Merci pour ces suggestions !

[tchize_]

Sous XP, je crois me souvenir d'un problème avec des versions passées de java concernant l'accélaration directx pour java2D.