Discussion :

[lea.soineca]

Voici mon code :

Je lis dans un buffer les données ligne par ligne et je les mets dans un variable result qui est en static.
Ensuite, j'affiche le result lorsque je sors de mon Thread. Pourquoi est -il vide?

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
 
private static String result = "";
public static void getTextOutput(final Process p) {
		new Thread() {
			public void run() {
				try {
					BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
					String lineBuffered = "";
					try {
						result = reader.readLine();
						while((lineBuffered = reader.readLine()) != null) {
							result += "\n" + lineBuffered;
						}
					} finally {
						reader.close();
					}
				} catch(IOException ioe) {
					ioe.printStackTrace();
				}
			}
		}.start();
		monLog.log(Level.WARNING," TEXT " +  result );
}

[thelvin]

La ligne monLog.log(Level.WARNING," TEXT " + result ); s'exécute bien avant que le tread ne commence à lire des données.

Tu dois bien évidemment attendre que le thread se termine, avant d'essayer de lire ses résultats -_-°. ... Et du coup on peut se demander à quoi ça servait de créer un thread puisque tu attends juste qu'il se termine.

[lea.soineca]

Ok !

J'exécute des lignes de commandes avec Runtime.getRuntime.exec()

Pour communiquer avec le processus executé, les différents flux doivent être traités depuis des threads différents, pour éviter des inter blocage!
http://ydisanto.developpez.com/tutor.../runtime-exec/

[thelvin]

Ok, mais dans l'exemple que tu donnes, il n'y a pas d'interaction (tu lis la sortie de l'autre processus, mais tu ne lui envoies rien du tout en entrée.) Il n'y a donc pas de risque d'interblocage.
... Mais dans des cas plus interactifs, effectivement.

[la.lune]

Pour éviter des interblocages si tu as une source partagé alors il faut penser à la synchronisation de la ressource.

Bon juste pour ton cas là affiché dans l'exemple si tu veux avoir le résultat avec les données.

N'importe où tu te trouves si tu es obligé de faire cette succession c'est simple, met ton/tes Thread(s) dans une/des variable(s) et fais appel la méthode thread.join() sur ton/tes thread après le thread.start() et avant de manipuler le résultat.

[la.lune]

Désolé je n'ai pas pris le temps d'aller voir l'exemple fourni dans le lien.

Déjà même avec un seul Thread et il attend la fin du processus pour afficher rien empêche de faire ça dans un Thread séparé si notre application peut faire autre chose, en plus si le procesus se bloc pourquoi on doit être nous aussi bloqué, on lui laisse faire son boulot séparément.

Là plutôt si tu as un seul thread et tu ne veux pas opter pour la solution prétendante il y a une solution plus simple , c'est d'introduire ton log dans la méthodes run dans le bloc finaly ou à la fin de la méthode

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
private static String result = "";
public static void getTextOutput(final Process p) {
        new Thread() {
            public void run() {
                try {
                    BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
                    String lineBuffered = "";
                    try {
                        result = reader.readLine();
                        while((lineBuffered = reader.readLine()) != null) {
                            result += "\n" + lineBuffered;
                        }
                    } finally {
                        reader.close();
                        monLog.log(Level.WARNING," TEXT " +  result );
                    }
                } catch(IOException ioe) {
                    ioe.printStackTrace();
                }
 
            }
        }.start();
 
}

[thelvin]

Dude, le thread ne sert à rien dans le code montré. Tu ne donneras aucun bon conseil en tirant des plans sur la comète.

[adiGuba]

Salut,

Ok, mais dans l'exemple que tu donnes, il n'y a pas d'interaction (tu lis la sortie de l'autre processus, mais tu ne lui envoies rien du tout en entrée.) Il n'y a donc pas de risque d'interblocage.

Le Thread ne sert à rien dans le cas présent...

Déjà dès qu'on fait un thread pour attendre son résultat immédiatement après c'est qu'on a un problème de conception dans l'utilisation du thread.


Toutefois si son traitement sur le process se limite à cela il y a quand même des risques d'interblocages s'il se contente de lire le flux de sortie !

• Si le process attend des données sur stdin, il va attendre longtemps.
• Si le process écrit beaucoup de données sur stderr, il peut remplir le buffer de communication avec l'appli Java, ce qui va lui provoquer un blocage I/O...

Si un de ces deux cas arrive, alors le Thread sera lui aussi bloqué puisque la lecture attendra la fin du process, et le process attendra soit des données, soit que le flux de sortie soit lu.

On peut affirmer que le process appelé ne fera jamais cela, mais on n'en est jamais sûr. Une configuration système ou autre peut provoquer l'affichage de message de confirmation ou activer des logs sut stderr...

Si on veut ignorer ces flux, il faut les fermer explicitement via close(), ainsi dans le process fils :

• Une lecture sur stdin provoquera un erreur (mais au moins cela ne devrait pas le bloquer).
• Les écritures dans stderr seront perdus (envoi vers /dev/null) mais ne bloqueront pas.

Plus de blocage !



Sinon pour revenir il y a plusieurs chose qui me dérange :

• Le "result" en static !!! Bref la méthode risque d'être inutilisable si on l'appelle plusieurs fois (surtout que tout est threadé dans ca risque d'être un beau bordel).
• La lecture par ligne qui ne sert à rien : pourquoi faire un découpage par ligne si au final on veut récupérer le contenu complet du fichier ?
• L'opérateur "+" (ou "+=") sur un String, qui est une vrai atrocité qui peut plomber les performances comme pas possible !

Perso je modifierais la méthode comme ceci, afin de lire le contenu d'un flux :

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
	public static String readAsText(final InputStream input) throws IOException {
		// Attention au Charset qui peut poser problème :
		Reader reader = new InputStreamReader(input);
		try {
			StringBuilder sb = new StringBuilder();
			char[] cbuf = new char[8192];
			int len;
			while ( (len=reader.read(cbuf)) > 0 ) {
				sb.append(cbuf, 0, len);
			}
			return sb.toString();
		} finally {
			reader.close();
		}
	}

Ensuite pour la lecture du process, si je veux uniquement le flux de sortie :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
	Process process = ...
	try {
		// On ferme le flux STDIN
		process.getOutputStream().close();
		// On ferme le flux STDERR :
		process.getErrorStream().close();
		// Puis on lit le résultat de STDOUT :
		String result = readAsText(process.getInputStream());
	} finally {
		// garde-fou en cas d'erreur : on tue le process
		process.destroy();
	}

A noter que depuis Java 5.0 on peut utiliser ProcessBuilder pour fusionner les flux stdout et stderr, ce qui permet de lire les deux en un seul flux.
Et depuis Java 7 cette même classe permet de rediriger les I/O du process vers les I/O du programme Java...




Maintenant si on doit traiter deux flux distinctement, il faut bien créer un thread pour que la lecture de chaque flux soit dans un thread séparé.
Par exemple pour lire stdout et stderr dans deux variables différentes, on commencera par faire une méthode readAsText() qui fonctionnera en tâche de fond.
Le plus simple étant d'utiliser FutureTask de Java 5.0 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
	public static Future<String> readAsTextInBackground(final InputStream input) {
		// 1. On crée une FutureTask avec notre traitement en tâche de fond :
		FutureTask<String> task = new FutureTask<>(new Callable<String>() {
			 @Override
			public String call() throws Exception {
				return readAsText(input);
			}
		});
		// 2. On démarre un Thread avec cette tâche :
		new Thread(task).start();
		// 3. On retourne l'objet Future permettant de récupérer le résultat :
		return task;
	}

Ce qui donne au final :

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
	Process process = null;
	try {
		// On ferme le flux STDIN
		process.getOutputStream().close();
		// On ferme le flux STDERR (en tâche de fond) :
		Future<String> stderrFuture = readAsTextInBackground(process.getErrorStream());
		// Puis on lit le résultat de STDOUT (bloquant) :
		String stdout = readAsText(process.getInputStream());
 
		// On récupère le resultat de la tâche de fond (bloquant) :
		String stderr = stderrFuture.get();
 
	} finally {
		process.destroy();
	}

a++

[lea.soineca]

Merci pour vos réponses !

En fait, ce que je fais :
1. je crée un processus grâce au Runtime.getRuntime().exec("./Processus")

2. J'initialise un tableau de String qui sont les noms de plusieurs fichiers et je parcours ce tableau.

3. Je lis un fichier .txt pour avoir un texte

4. Puis, j'envoie ce texte au processus grâce à OutputStreamWriter.

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
 
	public static void setTextInput(final Process p, final String linesToTurn) {
		new Thread() {
			public void run() {
				BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(p.getOutputStream()));
				try {
					writer.write(linesToTurn);
					writer.flush();
					writer.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
		}.start();
	}

5. Et, je lis la réponse que l'on me renvoit grâce à InputStreamReader.

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 static String readAsText(final InputStream input) throws IOException {
		// Attention au Charset qui peut poser problème :
		Reader reader = new InputStreamReader(input);
		try {
			StringBuilder sb = new StringBuilder();
			char[] cbuf = new char[8192];
			int len;
			while ( (len=reader.read(cbuf)) > 0 ) {
				sb.append(cbuf, 0, len);
			}
			return sb.toString();
		} finally {
			reader.close();
		}
	}

6. Et, je remet la réponse dans un autre fichier.

7. Puis je recommence à l'étape 3 mais avec le fichier suivant de mon tableau.

Au premier fichier, cela fonctionne mais pas pour les autres car cela est du au fait que à l'étape 4 et 5 je ferme les flux d'écriture et de lecture ce qui fait que le processus n'est plus en exécution.

Du coup je suis obligée à chaque lecture d'un fichier (étape 3) je dois relancer le processus (étape 1), ce qui ralenti les performances de mon application. Y a t-il un moyen d'éviter de relancer mon processus?

Par contre, si je ne ferme pas les flux, le code reste bloqué.

[adiGuba]

Difficile de te répondre sans savoir ce que fait "Processus", et plus précisément ce que tu veux faire.
Que fait ce processus ?


Tu parles de problème de performance : es-tu sûr que cela vient du processus ?

Par contre, si je ne ferme pas les flux, le code reste bloqué.

Dans ce cas il faut voir comment tu gères la communication entre ton appli Java et le processus.
Comme je l'ai déjà dit il ne suffit pas de faire un thread, il faut également gérer cela proprement...


a++

[lea.soineca]

Processus est un exécutable qui prend en entrée une chaine de caractère et qui la renvoie mais transformé.
Par exemple, lorsqu'on l'execute :

- on tape "coucou", cela renvoie "coucou".
- on tape "blabla", cela renvoie "blabla".
- on tape "stop", cela renvoie "Stop command received\n".
- on tape "start", cela renvoie "Start command received\n".

A chaque fois que je lis un nouveau fichier, je dois relancer Processus à l'aide de Runtime, ce qui me fait perdre en performance au niveau du temps d'execution de mon programme.

[thelvin]

Bon, mais le texte transformé, tu en fais quoi ?

Ce qu'il faut comprendre, c'est que quand tu lis la sortie d'un programme, rien a priori n'indique quand il a fini d'écrire une réponse à une entrée précise. Tu ne peux donc pas savoir quand est-ce qu'il faut cesser de lire des données, et qu'il est temps d'en envoyer des nouvelles.

- Si le but est d'envoyer toutes les réponses au même endroit, c'est pas grave, t'as pas besoin de savoir qui se termine quand. Tu dois juste balancer toutes les entrées dans l'ordre et lire toutes les sorties dans l'ordre, et t'arrêter quand il y en a plus.
- Si les réponses doivent aller chacune dans un fichier différent, là c'est plus compliqué. Tu vas avoir besoin d'un protocole pour séparer les réponses, et, du coup, séparer les questions. Ça peut être, en effet, d'arrêter le processus et d'en relancer un nouveau à chaque fois. Si ça ne te convient pas, il faut trouver autre chose. Par exemple décider que toutes les questions et toutes les réponses se terminent par une fin de ligne. Comme ça, tu sais qu'à chaque fin de ligne tu as reçu une réponse en entier.

[adiGuba]

Processus est un exécutable qui prend en entrée une chaine de caractère et qui la renvoie mais transformé.
Par exemple, lorsqu'on l'execute :

- on tape "coucou", cela renvoie "coucou".
- on tape "blabla", cela renvoie "blabla".
- on tape "stop", cela renvoie "Stop command received\n".
- on tape "start", cela renvoie "Start command received\n".

Si le processus répond bien une ligne pour chaque ligne écrite, tu peux enchainer une écriture et une lecture dans les flux du process (sans passer par des threads).
Par contre tu risques toujours un interblocage si le processus répond quelque chose de plus long...

A chaque fois que je lis un nouveau fichier, je dois relancer Processus à l'aide de Runtime, ce qui me fait perdre en performance au niveau du temps d'execution de mon programme.

C'est à dire ? Comment tu mesures cette perte de performance ? Es-tu sûr que cela vient bien du processus ?



a++

[tchize_]

Je crois que tu as un problème de conception à la base.

1) les wrapper que tu créer autour du processus (Reader/Writer) crée les une fois pour tout dès que tu as créé les processus.
2) faire un thread à part pour envoyer les message est une bonne chose. Mais il ne faut pas fermer le flux après. Juste faire un flush dessus. Tu n'aurais pas aussi oublié de mettre un retour à la ligne après ton message? Si tu n'en met pas, la pluspart des OS n'envoient rien au processus tant qu'il n'y a pas un \n ou que le flux est fermé. Ca expliquerait ton blocage.
3) pour la lecture, ça n'a pas de sens de mettre un thread à part, puisque le thread courant peux faire la lecture.


Ca resterait plus propre d'avoir un thread qui balance en boucle toutes les lignes du fichier et un autre qui lit en boucle tout les résultats. Cependant, cela n'a possible que si tu arrive à distinguer chaque résultat. Par exemple un par ligne comme c'est le cas actuellement. Ton code ressemblerait alors à ça:

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
Thread 1
  pour chaque ligne lu dans le fichier
     ecrire la ligne avec \n à la fin
  cloturer le stream
 
Thread 2
  pour chaque ligne lue depuis le process
    ajouter la ligne dans une liste
 cloturer le stream
 
Thread principal
  demarrer le processus
  créer les writer /reader
  cloturer stderr
  lancer thread 1
  lancer thread 2
  attendre la fin de thread 1 (join())
  attendre la fin de thread 2 (join())
  traiter les résultat ainsi obtenus.

[lea.soineca]

Si les réponses doivent aller chacune dans un fichier différent, là c'est plus compliqué. Tu vas avoir besoin d'un protocole pour séparer les réponses, et, du coup, séparer les questions. Ça peut être, en effet, d'arrêter le processus et d'en relancer un nouveau à chaque fois. Si ça ne te convient pas, il faut trouver autre chose. Par exemple décider que toutes les questions et toutes les réponses se terminent par une fin de ligne. Comme ça, tu sais qu'à chaque fin de ligne tu as reçu une réponse en entier.

Oui en effet, les réponses lu doivent aller chacune dans un fichier différent ! C'est pour cela, que arrêter le processus et d'en relancer un nouveau à chaque fois, cela fonctionne mais cela ne me plait pas car mon application doit être rapide à exécuter car il y a beaucoup de fichier à traiter. En faisant des System.currentTimeMillis(); un peu partout, je constate que 2/3 du temps d'execution est dédié à l'execution du Processus.

Je crois que tu as un problème de conception à la base.

Oui en effet ! Je pense avoir un gros problème de conception !

[lea.soineca]

Ce que je fais :

Thread 1
Ecrire le texte vers le process avec \n à la fin
cloturer le stream

Thread 2
Lit résultat depuis le process
renvoie le résultat au Thread principal
cloturer le stream

Thread principal
générer liste de nom de fichier.
for (parcours de liste de nom de fichier) {
demarrer le processus
créer les writer /reader
cloturer stderr
Lit fichier en entier et envoie au thread 1
lancer thread 1
lancer thread 2
attendre la fin de thread 1 (join())
attendre la fin de thread 2 (join())
traiter les résultat ainsi obtenus (en générant un nouveau fichier différent pour chaque tour de boucle avec les résultats).
}

Mais, je me demandais si il était possible de faire :

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
 
Thread 1
  Ecrire le texte vers le process avec \n à la fin
  cloturer le stream
 
Thread 2
  Lit résultat depuis le process
  renvoie le résultat au Thread principal
 cloturer le stream
 
Thread principal
  générer liste de nom de fichier.
  demarrer le processus
  créer les writer /reader
  cloturer stderr
  for (parcours de liste de nom de fichier) {
    Lit fichier en entier et envoie au thread 1
    lancer thread 1
    lancer thread 2
    attendre la fin de thread 1 (join())
    attendre la fin de thread 2 (join())
    traiter les résultat ainsi obtenus (en générant un nouveau fichier différent pour chaque tour de boucle avec les résultats).
  }

[thelvin]

Bah non, quand le stream est clôturé il est clôturé, fin de l'histoire, y a plus, nada.

Comme je te l'ai déjà dit, le problème est pour savoir que tu passes d'un fichier à l'autre. Si tu prévois rien pour l'indiquer, ben, rien ne l'indique. Il va falloir que tu conçoives un protocole qui indique début et fin du traitement. Ou que tu acceptes le simple protocole de fermer le processus et de le relancer à chaque traitement.

[lea.soineca]

Ok