Discussion :

[tchize_]

Bon j'ai pas tout compris sur la notion du interrupt().

interrupt() met le flag isInterrupted() du thread à true et interrompt immédiatement toute opération bloquante, typiquement de type IO, réseau ou sleep le supportant (typiquement, toutes les méthodes lancant un interruptedException).

quelle est la dif entre Thread et Runnable

Runnable est juste une interface contenant une méthode run. Thread est une classe permettant la création d'un thread et qui, lors du démarrage de ce thread, lance la méthode run d'un Runnable qui lui a été passé ou de lui même.

Les tâches ne sont pas lancées en parallèle, c'est important comme notion, si c'était le cas, tout échouerait.

Alors pourquoi tu va t'emmerder avec un executorService au lieu de faire une simple boucle sur toutes tes tâches?

Je voudrais que l'opération ne puisse pas être interrompue au milieu d'un fetch mais seulement avant ou après celui-ci.

Ben tu met tes tests où tu veux hein Par contre si tu ne veux pas arrêter au milieu d'un fetch -> tu oublie le interrupt(), car typiquement il pourrais interrompre un IO réseau à l'intérrieur de JDBC! Tu met juste une méthode type isTooLate() dans le parent qui va te renvoyer true ou false suivant l'heure ^^ . Méthode que tu appelle sagement entre chaque opération courte. Bien sur, ça veux dire qu'en cas d'interruption réseau prolongée, de lock de la DB, etc, ta tâche pourrais dépasser les 2h juste parce qu'elle attends 30 minutes une réponde de la DB

Dernière question, une fois qu'on a fait un shutdown sur l'Executor, est-il possible de le redémarrer ou il faut en instancier un tout beau tout neuf ?

Faire un nouveau, mais le executor c'est pour du paralléllisme qu'on utilise ça. Si t'as pas de parallélisme -> tu oublie, ça sert à rien d'en mettre pour le plaisir d'en mettre. T'as typiquement un batch d'opération qui doit s'interrompre à un moment. Ben tu met tout ça en série dans une boucle avec un check régulire sur l'heure ^^

[balsoc]

Code :

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

1
2
3
4
5
// Write lines one by one
while (!Thread.currentThread().isInterrupted() && rs.next())
{
        IOUtils.write(fetchResult(rs), outputStream);
}

Le shutdown du pool appellera interrupt sur chaque thread.

[adiGuba]

Ben tu met tes tests où tu veux hein Par contre si tu ne veux pas arrêter au milieu d'un fetch -> tu oublie le interrupt(), car typiquement il pourrais interrompre un IO réseau à l'intérrieur de JDBC!

Oui en effet je n'avais pas pensé à cela !

Tu met juste une méthode type isTooLate() dans le parent qui va te renvoyer true ou false suivant l'heure ^^ . Méthode que tu appelle sagement entre chaque opération courte.

Et surtout sans oublier de mettre ce champ en "volatile"


a++

[tchize_]

Oui en effet je n'avais pas pensé à cela !


Et surtout sans oublier de mettre ce champ en "volatile"

Pas besoin si la méthode calcule elle même le temps et qu'il n'y a pas d'autre thread

[BiM]

Merci pour vos réponses, vous battez pas

Ces éclaircissements m'aident beaucoup

Alors pourquoi tu va t'emmerder avec un executorService au lieu de faire une simple boucle sur toutes tes tâches?

J'utilise un Executor parce que c'était un Executor à la base et que j'ai pas envie de tout casser mais j'utilise cet Executor : executors.newSingleThreadExecutor(), ce qui me permet de les mettre dans la file d'exécution mais qu'ils s’exécutent les uns après les autres.

Voici à quoi ressemble mon Thread (Runnable plutôt), un truc très simple de test :

Code Java :

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
public class MyThread implements Runnable
{
    private String _valeur;
 
    public MyThread(String valeur)
    {
        _valeur = valeur;
    }
 
    public String getValeur()
    {
        return _valeur;
    }
 
    @Override
    public void run()
    {
        try
        {
            System.out.println("Début " + _valeur);
            Thread.sleep(2000);
            System.out.println("Fin " + _valeur);
        }
        catch (InterruptedException e)
        {
            System.err.println("Erreur " + _valeur);
        }
    }
}

Je gère le executor comme suit :

Code Java :

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
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.submit(new MyThread("Anne"));
executor.submit(new MyThread("Bertrand"));
executor.submit(new MyThread("Camille"));
executor.submit(new MyThread("Diane"));
executor.submit(new MyThread("Eric"));
executor.submit(new MyThread("Fabien"));
executor.submit(new MyThread("Gertrude"));
executor.submit(new MyThread("Hermione"));
executor.submit(new MyThread("Isabelle"));
executor.submit(new MyThread("Julien"));
 
executor.shutdown();
if (!executor.awaitTermination(11, TimeUnit.SECONDS))
{
    System.out.println("Not finished");
    executor.shutdownNow();
}
else
{
    System.out.println("Finished");
}

J'obtiens ça :

Début Anne
Fin Anne
Début Bertrand
Not finished
Erreur Bertrand

Donc lors du shutdownNow() qui est censé appelé les méthodes interrupt() des Thread en cours, le thread en question se prend un InterruptedException dans sa face Le thread ne continue donc pas son boulot tranquillement.

Juste une remarque : Perso je n'aime pas trop les try/catch/finally.
Je préfère largement les try/finally englobé dans un try/catch. C'est plus propre (on n'ignore pas les exceptions de fermeture du flux).

Vu le nombre de couches dans l'application, on va laisser comme ça, ça tourne très bien.

Tu peux faire quelquechose comme cela:

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
        ExecutorService executor = ...;
        Collection<Callable<Object>> tasks = ...;
 
        // Execute et attend la fin ou les 2 heures
        List<Future<Object>> futures = executor.invokeAll(tasks, 2, TimeUnit.HOURS);
 
        // Là, tout et fini ou les 2h se sont écoulées
        for (Future<Object> future : futures)
        {
            // On annule toutes les tâches non terminées, avec interruption si nécessaire
            if (!future.isDone())
            {
                // La tâche ne sera pas lancée
                future.cancel(true);
            }
        }
 
        // on achève l'executor pour libérer les resources
        executor.shutdown();

Intéressant. Je vais tenter ce type de solution. Mais le problème des interrupt est toujours le même. Il s'avère que invokeAll correspond quand même carrément à mon besoin (j'en ai l'impression), merci

Note: Je soupçonne la 2e partie de mon code d'être équivalente à un appel à shutdownNow().

Après analyse du shutdown de l'Executor, il interrompt tous les Thread en cours par un interrupt().

interrupt() met le flag isInterrupted() du thread à true et interrompt immédiatement toute opération bloquante, typiquement de type IO, réseau ou sleep le supportant (typiquement, toutes les méthodes lancant un interruptedException).

Ca doit être pour ça que j'ai une Exception ci-dessus, mais ça risque d'être pareil lors de l'écriture dans un fichier, non ?

Code :

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

1
2
3
4
5
// Write lines one by one
while (!Thread.currentThread().isInterrupted() && rs.next())
{
        IOUtils.write(fetchResult(rs), outputStream);
}

Le shutdown du pool appellera interrupt sur chaque thread.

C'est bien ce qui me semblait, mais bon toujours ce problème d'IO à priori.

[tchize_]

Ca doit être pour ça que j'ai une Exception ci-dessus, mais ça risque d'être pareil lors de l'écriture dans un fichier, non ?

Ben oui, c'est le but de interrupt. Comme je l'ai dit, si tu veux pouvoir finir ta transaction DB, ta lecture ou cloturer ton fichier, l'interrupt n'est pas le bon choix. Du coup l'exécutor n'est plus le bon choix non plus

[BiM]

Bon disons que c'est pas grave si je finis pas d'écrire ma ligne. Au pire, je me choppe un InterruptedException, et dans le finally, je ferme proprement le fichier (ou la connexion à la DB selon l'emplacement où je me trouve), c'est ça ?

[tchize_]

ben oui, c'est toi qui disais que tu voulais terminer ton fetch.

[BiM]

ben oui, c'est toi qui disais que tu voulais terminer ton fetch.

Oui mais au final je me rends compte qu'il y a trop de choses à modifier.