Discussion :

[haskouse]

Bonjour les amis,

J'ai besoin d'un petit coup de main, en fait j'ai créé une fonction qui fait un calcul selon un paramètre M, cette fonction peu prendre parfois beaucoup de temps pour s'exécuter et ce temps d'exécution peu changer (diminuer ou bien augmenter) si on change le paramètre M. Je voudrais savoir s'il y'a un moyen de lancer la fonction avec un paramètre M (valeur 1 par exemple) et si le temps d’exécution dépasse 30 seconds, arrêter le traitement et le relancer avec M' (valeur 2 par exemple), et même chose, si cela prend plus de 30 secondes arrêter de nouveau puis relancer avec M'' (valeur 3) et ainsi de suite ...

Merci par avance pour vos réponses.

[Jimmy_]

Oui tu peux par exemple lancer le traitement dans un thread que tu stoppes dès que ton timeout est terminé. Et tu en relances un autre ...

Va voir du coté de l'objet Thread.

Il doit y avoir bien d'autres façon de faire.

[haskouse]

Bon j'ai fais plusieurs recherches mais je bloque toujours.

Pour l'instant voilà ce que j'ai fait.
J'ai créé deux Thread, le premier lance le calcul ThreadCalculator, le deuxième il lance un compteur qui va compter le nombre de secondes écoulé : ThreadTimer.

ThreadCalculator : dans son RUN il lance une fonction (que je ne peux pas modifier), il récupère le résultat dans une variable.

ThreadTimer : dans son RUN il lance une boucle pour une période donnée, cette période je la lui passe par un paramètre NBRSECONDES, si par exemple NBRSECONDES = 5, alors le Thread se lancerea 5 secondes puis va sortir.

Voilà le problème :
Dans mon main, je lance les deux Thread successivement, Si ThreadCalculator se términe avant le ThreadTimer alors c'est bon. Mais si le ThreadTimer se términe avant le ThreadCalculator là je galère, car il faut que j'arrête les deux thread, puis que je les relance en changeant un paramètre pour le ThreadCalculator (un paramètre qui permettra de réduite son temps d'execution).

Quand j'arrête les deux Thread avec STOP ( ce qui est complètement déprécié , si vous avez une autre méthode je suis preneur ) je les relance, et là ça ne marche pas, en me donnant l'excetion suivante :

Code :

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

1
2
java.lang.IllegalThreadStateException
    at java.lang.Thread.start

[deathness]

Ne faut il pas que tu les recrées?

[hwoarang]

Le mieux dans ce genre de cas, c'est d'utiliser un flag dans la fonction lente qui sera periodiquement verifié. Comme ca, pour l'arreter, il suffit de changer le flag puis d'utiliser un Thread.join(). Ca permet de sortir de maniere plus propre et de liberer les ressources eventuellement utilisées proprement.

Un truc du genre :

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
Thread t;
private void startFonctionLente()
{
   t = new Thread(new Runnable()
   {
      fonctionLente();
   });
}
 
private void fonctionLente()
{
   int i = 0;
   while((stopFlag== false) && (i < 50))
   {
      // Une partie du traitement
      i++;
   }
}
 
public void stopFonctionLente()
{
   stopFlag = true;
   try
   {
      t.join();
   }
}

a+

[haskouse]

Oui j'avais pensé à ça, mais comme j'ai dis précedemment je n'ai pas accès au code source de la fonction lente, je ne peux qu'y faire appel, elle fourni dans un jar.
Pas accès au code source --> pas de flag possible :'(

[thelvin]

Oui j'avais pensé à ça, mais comme j'ai dis précedemment je n'ai pas accès au code source de la fonction lente, je ne peux qu'y faire appel, elle fourni dans un jar.
Pas accès au code source --> pas de flag possible :'(

Dommage, il va donc falloir les refaire par toi-même.
Ou bien renoncer à interrompre ces appels.

[haskouse]

Ne faut il pas que tu les recrées?

C'était une bonne piste, merci encore, j'ai réussi à résoudre mon problème mais en utilisant quand même la fonction STOP() une fois. Je n'avais pas d'autre choix. Voilà comment j'ai procédé

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
 
        ThreadTimer tt = new ThreadTimer();
        ThreadCalculator tc = new ThreadCalculator();
 
        int param = 100000000;
        int timeout = 2;
 
        tt.setNbrSecondes(timeout);
        tt.start();
 
        System.out.println("Test avec param = " + param);
        tc.setParametre(param);
        tc.start();
 
do {
            while (tt.isContinuer() && tc.isContinuer()) {
            }
 
            if (!tc.isContinuer()) {
                tt.setContinuer(false);
                System.out.println("calcul terminé");
 
                System.out.println("Facto(" + tc.getParametre() + ") = "
                        + tc.getResultat());
                break;
            }
 
            if (!tt.isContinuer() && tc.isContinuer()) {
 
                System.out.println("temps écoulé");
 
                tt.setContinuer(false);
                tt = new ThreadTimer();
                tt.setNbrSecondes(timeout);
                tt.setContinuer(true);
                tt.start();
 
                param -= 10000000;
                tc.stop();
                tc = new ThreadCalculator();
                System.out.println("Test avec param = " + param);
                tc.setParametre(param);
                tc.start();
            }
 
        } while (tc.isContinuer());

avec les deux fonction RUN suivantes :
ThreadTimer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public void run() {
 
        long start = System.currentTimeMillis();
 
        while (continuer
                && (System.currentTimeMillis() - start) / 1000 < nbrSecondes) {
 
        }
 
        continuer = false;
    }

ThreadCalculator :

Code :

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

1
2
3
4
5
@Override
    public void run() {
        this.resultat = ClasseMetier.facto(this.parametre);
        this.continuer = false;
    }

ClasseMetier étant la classe qui contient la fonction 'facto' qui est lente et qui ne peut être modifié.

J'éspère que ce post pourra aider quelqu'un vu que j'ai galéré pendant une semaine avant d'arriver à cette solution.

Sinon si vous voyez que ce code peut encore être amélioré je suis preneur ( surtout pour éliminer la fonction STOP())

Merci encore.

[haskouse]

Pour les personnes qui veulent faire un test je mets en pièce jointe l'ensemble des classes. Bonne chance.

N.B : la classe ClasseMetier étant modifiable ici, je n'ai pas mis la vraie (celle qui posait problème :'()

[tchize_]

Il faut que ta fonction collabore d'une manière ou d'une autre, sinon c'est cuit.

Si t'as pas la main mise sur le fonction (ce qui arrive), il faut regarder si tu n'a pas la main mise en aval sur l'un ou l'autre listener, souces de données etc que la fonction utiliserais et que tu fournirais. Dans ce dernier cas tu peux faire la vérification dans une de ces classes de support et faire remonter une RuntimeException pour arrêter l'appel.

En dernier recours, il faudra envisager de lancer ce calcul dans une jvm séparée que tu pourrais alors tuer.

[haskouse]

En fait je n'ai aucun moyen d'agir sur la fonction. En effet pour bien comprendre il s'agit d'une fonction qui va résoudre un problème en utilisant la programmation par contrainte, cette fonction j'y fais appel après que j'ai décris toutes mes contraintes, ensuite elle fait des calculs internes (le code est caché) et ce calcul peut prendre quelques secondes comme il peut prendre des jours selon la complexité du problème.
Bref aucun moyen d'agir sur la fonction en aval car elle n'a pas de source externe.

[Djakisback]

Salut,
une soluce plus simple inspirée d'un post sur DVP à base de TimerTask et toujours avec stop() mais de toute façon je crois que tu n'as pas beaucoup le choix sans accès à la méthode lente :

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
import java.util.Timer;
import java.util.TimerTask;
 
 
public class Test {
 
	public static Thread t;
 
	public static void boucleInfinie(int m)	{
		while(true)	{
			System.out.println("Test.boucleInfinie(): " + ++m);
		}
	}
 
	/**
         * @param args
         */
	public static void main(String[] args) {
 
		long msDelay = 5000; // 5 secs
		Timer timer = new Timer();
 
		// Méthode lente
		t = new Thread() { public void run()		{
			boucleInfinie(0);
		} } ;
		t.start();
 
		// Tâche d'arrêt
		TimerTask task = new TimerTask() {    
	        @Override
	        public void run() {
	    		t.stop();
	        }
		};
		timer.schedule(task, msDelay);
	}
}

[tchize_]

Stop est déprécié pour une bonne raison. Après un appel à stop t'es de toutes façons bon pour arrêter ta JVM vu l'état dans lequel ça peux potentiellement laisser les données, les verrous internes, etc.

[haskouse]

Oui je sais, j'ai lu la doc sur cette fonction, mais le problème c'est que je ne peux pas m'en passer. Tu n'aurais pas une autre idée pour contourner le problème ? J'ai lu un truc par rapport à Interrupt() mais je n'ai pas bien assimilé, peut être ce serait un moyen à utiliser.

[thelvin]

Tu n'aurais pas une autre idée pour contourner le problème ?

Lancer les trucs que tu veux pouvoir interrompre dans un autre processus, avec ProcessBuilder, comme si tu lançais une commande externe non-Java, sauf que tu t'en sers pour lancer un autre programme Java qui, du coup, peut être interrompu sans risque.
Pour l'interrompre, appelle destroy() sur le Process créé. C'est (très) lourd et il faut déterminer quelle est la commande pour appeler un autre programme Java, mais ça marche.
Vu que ce sera un processus séparé, l'arrêter dans un état instable ne pose aucun problème pour le processus en cours.

J'ai lu un truc par rapport à Interrupt() mais je n'ai pas bien assimilé, peut être ce serait un moyen à utiliser.

Ben, c'est ce qui remplace stop(). Tu appelles interrupt() au lieu de stop(), et si le thread en question gère les interruptions, il va s'arrêter quelques microsecondes plus tard.
S'il ne gère pas les interruptions, par contre, ça ne l'arrêtera que juste avant qu'il soit sur le point de se terminer normalement (bref ça marchera pas).

Ce n'est pas si difficile de modifier un programme pour qu'il gère les interruptions, mais si tu ne peux pas modifier cette partie-là, rien à faire.

[Djakisback]

Sur ce coup là, un kill ou un stop, c'est la même chose. De mon côté j'ai toujours eu un peu de mal avec le depreciated du stop et d'autres trucs en Java.
Bordel ! Si on veut kill un thread se faire un pti deadlock ou une petite fuite, je vois pas où est le souci, laissez nous travailler, monsieur xxxx.

[tchize_]

interrupt() ne remplace pas vraiment stop. Le but de interrupt est de réveiller un Thread d'une opération bloquante (sleep, attente d'un sémaphore, IO) afin qu'il puisse se rendre compte de "quelque chose". Bref, il faut deux conditions:

1) Que ta fonction appelle des méthodes de java lançant des InterruptedException
2) Qu'elle traite correctement les InterruptedException (à savoir qu'elle interrompte ses calculs). Sachant que 99.9% des codes qu'il m'a été donné de voir se contentent d'afficher un message dans la console, c'est peu utile.


Un autre possibilité qui me viens éventuellement en tête, c'est, si il y a des méthodes protected dans la classe de calcul, de surcharger ces méthodes pour rajouter ton code de test.

Si ce n'est pas possible (méthodes private, méthodes protected), l'utilisation de l'aop (Programmation orientée aspect) peux éventuellement te sauver. Avec l'aop on peux ajouter du code entourant des méthodes voir carrément les remplacer. Des outils comme jmockit ou spring-aop en font usage et sont plus facile d'utilisation que les librairies aop brutes (exemple aspectj). Tu pourrais alors t'insinuer dans une ou plusieurs méthodes privées du calcul pour faire tes tests sur le flag et, suivant le résultat du test, lancer une RuntimeException qui arrêterais le calcul. Ainsi tu reste propre (état stable du Thread), tu n'a pas besoin de modifier les sources. Par contre, c'est complexe à mettre en oeuvre et sujet à ne plus marcher le jour où tu met à jour la librairie en question. (Car t'es lié aux méthodes privées)

Avec Spring, par exemple, tu pourrais demander à spring de faire de l'injection AOP pour avoir une "pré méthode" appelée avant ces différentes méthodes de calculs

[tchize_]

Bordel ! Si on veut kill un thread se faire un pti deadlock ou une petite fuite, je vois pas où est le souci, laissez nous travailler, monsieur xxxx.

C'est pas un "petit" deadlock ou une "petite" fuite. Si tu tombe mal lors du kill, ça peux être le garbage collector, le système d'IOs ou tout autre composante de base de la jvm que tu pourris. Et après, on se gratte la tête pour savoir pourquoi la jvm crashe sur un sigsegv.

[thelvin]

Le but de interrupt est de réveiller un Thread d'une opération bloquante (sleep, attente d'un sémaphore, IO) afin qu'il puisse se rendre compte de "quelque chose".

Ou de placer son flag interrupted à true pour qu'il puisse s'en rendre compte en appelant isInterrupted(), par exemple dans une boucle très très longue qui ne fait aucun appel bloquant.

C'est pas un "petit" deadlock ou une "petite" fuite. Si tu tombe mal lors du kill, ça peux être le garbage collector, le système d'IOs ou tout autre composante de base de la jvm que tu pourris. Et après, on se gratte la tête pour savoir pourquoi la jvm crashe sur un sigsegv.

+1.

Après, certains pourraient se dire que vu la faible probabilité (faible probabilité au nom de quoi, au juste ?,) le risque de se retrouver avec une JVM totalement délirante est acceptable si c'est juste pour afficher des résultats mesurables et arrêter le programme tout de suite après.
Oui, sans doute, mais le problème c'est que ce n'est pas assez expliqué. Si le but est d'arrêter entièrement le programme tout de suite après, et qu'il n'est pas relié à quoi que ce soit en production, ok, ça se tient. Moi, personne informée, je refuse de tenir compte de quoi que ce soit produit comme ça, mais chacun en fera ce qu'il veut.

Mais la réalité c'est que le but n'est jamais ça. Le but est d'avoir des résultats fiables, utilisables en production, et de ne pas arrêter le programme après l'interruption. Et stop() est contradictoire à chacun de ces besoins. Quand on en parle il faut donc l'enseigner comme tel, très clairement, et pas autrement.

[Djakisback]

C'est pas un "petit" deadlock ou une "petite" fuite. Si tu tombe mal lors du kill, ça peux être le garbage collector, le système d'IOs ou tout autre composante de base de la jvm que tu pourris. Et après, on se gratte la tête pour savoir pourquoi la jvm crashe sur un sigsegv.

Oui en fait, je faisais juste une remarque générale sur Java, qu'était peut-être un peu déplacée pour le sujet mais la dépréciation de méthodes comme stop() m'ennuie car on assiste de plus en plus le développeur...