J’ai un léger petit soucis en Java, j’ai programmé un suite de tests avec JUnit qui doit créer un serveur, dialoguer et vérifier que le tout s’est bien passé ou que les erreurs générer sont correctes selon les cas pour chaque test.
Seulement, j’ai un petit soucis entre les différents tests, car JUnit lance le test suivant sans attendre que le serveur du tests précédants se soit bien arrété comment faire pour obliger l’attente de la fermeture du serveur avant d’essayé d’en recréer un.
Tout ceci n’est qu’un problème de thread.
il doit y avoir des methode wait ou autre qui te permettent d’attendre la terminaison d’un thread
il faut utiliser les méthode wait() et notify() mais je ne comprend pas trop comment.
[quote name=‹ ZGoblin › date=’ 16 Feb 2005, 01:29’]il faut utiliser les méthode wait() et notify() mais je ne comprend pas trop comment.
[right][post=« 333210 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Cadeau Normalement tu vois tout ca en cours si t’as fait des cours d’info avec des philosophes qui bouffent des spaghettis et qui ont pas assez de fourchettes. Genial le mec qui a invente ce moyen didactique vraiment realiste
En fait, j’ai plutot l’impression que mon serveur ne se stoppe voici le code :
[code]package org.fptzobe.net;
import java.net.ServerSocket;
public class Serveur implements Runnable
{
public static final int PORT = 5049;
private Thread thread;
private FptUI ui;
public Serveur(FptUI ui)
{
this.ui = ui;
}
public void start()
{
thread = new Thread(this);
thread.start();
}
public void stop()
{
if (thread != null) {
thread.stop();
thread = null;
}
}
public void run()
{
try {
System.out.println(“attente…”);
ServerSocket socketServeur = new ServerSocket(PORT);
while (true) {
new ConnectionIn(socketServeur.accept(), ui);
System.out.println(“Connection réussie”);
}
} catch (Exception e) {
e.printStackTrace();
}
}
}[/code]
Un serveur tout simple mais il doit y avoir une couille quelque part.
Il faut jamais utiliser Thread.Stop() comme tu as ptet remarque a la compilation Stop et Suspend sone deprecated. Y a une bonne raison Mattes sur les liens que je t’ai file. En Java arreter un thread est pas trivial du tout, meme dans ton exemple tout simple, surtout quand il s’agit de fermer tout un serveur proprement, dans le bon ordre sans risquer de deadlock ou de race condition. Ils ont fait un effort dans java 1.5 d’ailleurs sur lequel je m’astiendrais de commenter
C’est pas super super complique mais il faut bien comprendre ce que tu fais. Fais aussi une recherche sur java, stop thread tu vas voir le bordel :P…
Tiens, ca, ca a l’air pas mal.
[quote name=‹ GloP › date=’ 16 Feb 2005, 11:19’]Il faut jamais utiliser Thread.Stop() comme tu as ptet remarque a la compilation Stop et Suspend sone deprecated. Y a une bonne raison Mattes sur les liens que je t’ai file. En Java arreter un thread est pas trivial du tout, meme dans ton exemple tout simple, surtout quand il s’agit de fermer tout un serveur proprement, dans le bon ordre sans risquer de deadlock ou de race condition. Ils ont fait un effort dans java 1.5 d’ailleurs sur lequel je m’astiendrais de commenter
C’est pas super super complique mais il faut bien comprendre ce que tu fais. Fais aussi une recherche sur java, stop thread tu vas voir le bordel :P…
Tiens, ca, ca a l’air pas mal.
[right][post=« 333242 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Je suis une grosse bouse, pour le thread.stop(), voici la correction :
[quote] public void stop()
{
if (thread != null) {
thread = null;
try {
socketServeur.close();
} catch(IOException e) {
e.printStackTrace();
}
}
}
public void run()
{
try {
System.out.println(« attente… »);
socketServeur = new ServerSocket(PORT);
Thread thisThread = Thread.currentThread();
while (thread == thisThread) {
new ConnectionIn(socketServeur.accept(), ui);
System.out.println(« Connection réussie »);
}
} catch (IOException e) {
System.out.println(« Connection fermée »);
}
}[/quote]
Je paniquais un peu à cause de l’exception levée lors socketServeur.close(), alors que celle-ci est tout à fait normal selon la doc.
On voit que ça fait plus d’un an que je n’ai plus touché au réseau.
Après avoir réglé ce problème de thread pour mes serveur et clients réseaux, j’ai un autre problème qui implique l’interface graphique.
Pour faire simple, j’ai un thread qui est créé par le serveur à chaque connection, normal.
Ce thread appelle une méthode de l’UI : public File acceptFile(String sender, String filename);
ensuite le serveur sauvegarde l’arrivé du flux réseaux dans le fichier.
Tout se passait bien lorsque ma méthode acceptFile ressemblé à ça :
public File acceptFile(String sender, String nameFile)
{
System.out.println("accepter le fichier " + nameFile + " de " + sender + " ? y");
return new File("d:\\test2.jpg");
}
Maintenant, que ça ressemble à ça, l’interface plante :
/**
* Demande à l'utilisateur si il accepte le fichier
*/
public File acceptFile(String sender, String nameFile)
{
String filenameInternal;
chooser.resetChoosableFileFilters();
chooser.setDialogType(JFileChooser.SAVE_DIALOG);
filenameInternal = chooseFile();
if(filenameInternal == null)
return null;
return new File(filenameInternal);
}
J’ai essayé pas mal de chose sans succé, je n’ai plus aucune idée.
Je sais pas comment ca marche en Java mais a priori tout la UI doit etre dans un seul thread, celui qui fait tourner la message pump. Donc pas d’appel pour montrer des dialogues ou quoi dans des threads differents. Si un thread doit updater la UI il soit “signaler” a la UI de s’updater ou poster un message avec les params qu’il faut. Y a juste pas de moyens evidents/faciles/faisables de faire tourner une message pump en multi thread.
[quote name=‘GloP’ date=’ 22 Feb 2005, 11:51’]Je sais pas comment ca marche en Java mais a priori tout la UI doit etre dans un seul thread, celui qui fait tourner la message pump. Donc pas d’appel pour montrer des dialogues ou quoi dans des threads differents. Si un thread doit updater la UI il soit “signaler” a la UI de s’updater ou poster un message avec les params qu’il faut. Y a juste pas de moyens evidents/faciles/faisables de faire tourner une message pump en multi thread.
[right][post=“335006”]<{POST_SNAPBACK}>[/post][/right][/quote]
Effectivement, j’ai deux autres solutions mais qui semblent trop compliqué :
-
un système Observeur<->Observé mais ca ne va que dans un sens donc c’est pas top pour faire transiter des infos dans les deux sens, en plus je ne suis même pas sur que ca me rêgle les problèmes.
-
un mini serveur en local, ca me semble ce qui pourrait fonctionner le mieux, le thread qui a la connection distante communique avec l’interface graphique via une connection réseau en local. Ca me semble assez lourd aussi mais je ne vois pas plus simple pour l’instant.
Il faut aussi que je regarde du coté de SwingUtilities.invokeLater(Thread t) mais pour l’instant je me prend des grosse exception donc je vais laisser refroidir pour reprendre ça au calme plus tard.
La solution se fait du coté serveur :
[code]
final File[] file = new File[1];
Runnable getFile =
new Runnable() {
public void run() {
file[0] = ui.acceptFile((String) infos.get(Serveur.PSEUDO),
(String) infos.get(Serveur.FILENAME));
}
};
SwingUtilities.invokeAndWait
(getFile);[/code]
Voilà, j’ai l’impression de parler un peu tout seul dans ce post :P"
Mais non je suis la La preuve y a que moi qui repond hehe.