Discussion :

[taillooo]

Bonjour a tous,
voila, tout est dans le titre :-)
les methodes permettant de recuperer l'etat d'un thread de la classe Thread sont apparues dans le 1.5, mon appli tourne en 1.4 et je souhaiterai detecter automatiquement si un thread bloque ou non. J'ai aussi vu la classe ThreadInfo mais elle est egalement en 1.5.
Auriez vous une idée ? Comment faisait-on a cette "epoque" la ? :-)

Merci d'avance de votre aide

[KahRiboo]

Alors en 1.4.2 tu as deja qq informations sur tes Threads :

boolean isAlive() Tests if this thread is alive.
boolean isDaemon() Tests if this thread is a daemon thread.
boolean isInterrupted() Tests whether this thread has been interrupted.

Apres si tu veux savoir si un Thread est bloqué... tout dépends de ce que tu apelle bloqué ?
- en cours d'execution --> test avec isAlive()
- bloqué dans son execution --> tu peux le faire à la main (en gros)

Exemple de monitoring :

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
 
package com.coface.corp;
 
public class ExThread {
	public static final int CREATED = 0 ;
	public static final int STARTED = 1 ;
	public static final int RUNNING = 2 ;
	public static final int ENDING = 3 ;
	public static final int ENDED = 4 ;
	public static final int BLOCKED = 5 ;
 
	public static final long MAX_DURATION_ALLOWED = 60 * 1000; // One minute
 
	private long lastActionTime ;
	private int state = CREATED;
 
	public void run() {
		state = STARTED ;
 
		// TODO do init here
 
		lastActionTime = System.currentTimeMillis() ;
		state = RUNNING ;
 
		boolean condition = true;
		while (condition) {
 
			lastActionTime = System.currentTimeMillis() ;
 
			// TODO do task here (we suppose the task can't be more longer than MAX_DURATION_ALLOWED)
		}
 
		state = ENDING ; 
 
		// TODO do clean here
 
		state = ENDED ;
	}
 
	public int getState() {
		if (state == RUNNING && System.currentTimeMillis() - lastActionTime > MAX_DURATION_ALLOWED) {
			return BLOCKED ;
		}
		return state ;
	}
}

Sachant qu'il faut que tu puisse estimer ici la durée maximum de ton traitement apres laquelle tu considere ton Thread comme bloqué...

J'espere que ceal pourra t'aider
K.

[taillooo]

bonjour KahRiboo,
merci de ta réponse et de ton code.
Il est vrai que je n'ai pas été tres précis sur ce que je veux. Pour moi le isAlive ne m'est d'aucune utilité car je désire savoir s'il est bloqué dans son exécution.

Je me doutais bien qu'on peut le faire de cette facon, mais malheureusement je ne peut surcharger le thread que je veux "ecouter" car il s'agit de l'EDT (eh oui je veux detecter un freeze sans etre devant l'ecran). La seule methode que j'avais en tête etait de lui faire incrementer un compteur et de checker ce compteur regulierement, mais je ne trouve pas ca tres prorpre.

Donc, je continue de chercher.

Merci encore!

[KahRiboo]

Pour ma culture générale (et on sait jamais ca me donnera peut-être une idée de piste a suivre) ...

C'est quoi ce Thread de l' "EDT" ?

[adiGuba]

Salut,

(Note : j'ai déplacé ce sujet depuis le forum langage où il était posté initialement)

C'est quoi ce Thread de l' "EDT" ?

L'EDT est le thread qui gère l'interface graphique AWT/Swing. Il s'agit en fait qu'une queue de traitement à effectuer qui boucle sans fin, et parmi lesquels on retrouve la mise à jour de l'affichage et la gestion des évènement.

Le problème étant que l'on doit utiliser ce thread pour modifier l'interface graphique, mais qu'on doit éviter d'y faire des traitements lourds car sinon l'affichage ne sera plus mise à jours (interface figé et bug du "rectangle gris").

Plus d'info : http://gfx.developpez.com/tutoriel/j...ing-threading/




taillooo >> si j'ai bien compris tu voudrais pouvoir surveiller l'EDT pour détecter les codes qui prennent trop de temps et risquerait de bloquer l'interface...

Dans ce cas tu pourrais redéfinir l'EventQueue c'est à dire la classe qui gère la queue d'évènement qui sera traité par l'EDT. Ainsi c'est la méthode dispatchEvent() qui s'occupe de traiter les évènements, et tu pourrais la redéfinir pour calculer sa durée d'exécution :

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
public class TimedEventQueue extends java.awt.EventQueue {
 
	protected void dispatchEvent(AWTEvent event) {
 
		// On appelle la méthode parente en calculant sa durée
		long time = System.currentTimeMillis();
		super.dispatchEvent(event);
		time = System.currentTimeMillis() - time;
 
		// Si cette durée dépasse une certaine valeur on l'affiche :
		if (time>100) {
			System.err.println(time + " ms : " + event);
		}
 
	}
}

Ensuite il te suffit simplement d'écraser l'EventQueue par défaut par le tiens (au tout début du programme par exemple) :

Code :

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

Toolkit.getDefaultToolkit().getSystemEventQueue().push(new TimedEventQueue());

a++

[taillooo]

Waow! ca c tres interessant :-)
Merci du coup de main adiGuba

Par contre, je ne suis pas bien sûr de tout saisir. Dans le morceau de code suivant

Code :

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

1
2
3
4
 
long time = System.currentTimeMillis();
super.dispatchEvent(event);
time = System.currentTimeMillis() - time;

si l'EDT bloque c justement dans l'appel à super.dispatchEvent(event);, non ? Donc on ira pas jusqu'au calcul de la 3e ligne.
Et si je me trompe et que ce n'est qu'un envoi au thread, on a juste le temps de l'envoi et non celle de l'execution, donc pas l'info voulue... Ou alors j'ai pas bien compris le fonctionnement :-) Tu pourrais eclairer encore un peu ma lanterne, stp ?

Merci pour tes explications!

[herve91]

si l'EDT bloque c justement dans l'appel à super.dispatchEvent(event);, non ? Donc on ira pas jusqu'au calcul de la 3e ligne.

Oui, c'est tout à fait vrai. Ce que tu peux faire c'est monitorer l'exécution de l'EDT via un thread tiers, par exemple un Timer qui viendrait checker régulièrement l'avancement d'un timestamp placé dans la classe TimedEventQueue.

Et si je me trompe et que ce n'est qu'un envoi au thread, on a juste le temps de l'envoi et non celle de l'execution, donc pas l'info voulue...

Non, il ne s'agit pas d'un "envoi", c'est bien le thread EDT qui exécute la méthode dispatchEvent(). On a donc bien le temps d'exécution de la méthode.

[adiGuba]

Et si je me trompe et que ce n'est qu'un envoi au thread, on a juste le temps de l'envoi et non celle de l'execution, donc pas l'info voulue... Ou alors j'ai pas bien compris le fonctionnement :-) Tu pourrais eclairer encore un peu ma lanterne, stp ?

Non on est déjà dans l'EDT et dispatchEvent() générera tous les traitement lié à l'evenement. Ce code permet seulement de déceler et de logger les traitements trop long qui sont effectué dans l'EDT...

a++

[taillooo]

Bonjour et merci a tous les 2 pour vos reponses.
Je pense que je vais en effet me diriger vers cette solution Herve91... mais vivement que mon appli passe en java 1.5 ! :-)

Merci encore et bonne journée!