[JAVA] Probleme de surcharge CPU

Recherche :

Dernière réponse

Sujet : [JAVA] Probleme de surcharge CPU

Cherrytree

gfive a écrit a écrit :

En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!! :D

Ah ! Qui sait, si ça se trouve il déteste programmer en Visual C++. Si ça se trouve, il déteste programmer :D

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

Cherrytree

gfive a écrit a écrit :

En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!! :D

Ah ! Qui sait, si ça se trouve il déteste programmer en Visual C++. Si ça se trouve, il déteste programmer :D

gfive

En java, c'est pas bill le plus fort, en tout cas, ça, c'est sûr!! :D

benou

Cherrytree a écrit a écrit :

:) :) :) Alors, qui c'est le plus fort ?

nananan ... ose pas me comparer à dark : il maîtrise bien plus de domaine que moi en Java !! :jap:

Cherrytree

darklord22 a écrit a écrit :

damn!

benou :gun: :gun: :gun:

:D

bien vu :fou:

:) :) :) Alors, qui c'est le plus fort ?

Solution : Facile, c'est Bill Gates. En anglais on dit qu'il a une "fucking policy". Une politique enculante, quoi !

gfive

shit!! :D

axel5

oui... mais la voila, j'ai pas la main sur le protocole client, faut donc faire avek ! :crazy:

gfive

Ah ouais...J'ai fait autrement, pour l'acquitement, moi....: comme j'en attend pas toujours, j'ai un système d'objects qui attendent : quand j'envoie un message pour lequel je dois attendre une réponse, je met mon objet qui attend dans une HashMap, indexé par l'Id du message....Quand un acquitement est reçu, je lis l'ID, et si un objet attend cet Id là, j'appelle la méthode à appeller quand l'Id est reçu....

axel5

gfive > le pb c'est que le client envoye des messages (on attend avec un receive donc bloquant) et on lui renvoie un aquittement, et on rempile sur le receive.... a coté de ca, on peut avoir a tt moment a lui envoyer des messages... avec un seul thread, on serait obligé d'attendre de recevoir un msg pour pourvoir renvoyer le notre apres aquittement... d'ou un second thread avec section critique

gfive

On a installé mardi, entre 2h et 7h!! :D
Et là, première rafale de corrections à faire!! :D

Mais je bosse pas chez Orange, je bosse dans une p'tite boite qui bosse pour orange.

darklord22

t'as bossé pour orange?

benou

darklord22 a écrit a écrit :

damn!benou :gun: :gun: :gun:

mdr ! :D

gfive

Ouais, mais ça fait un an que je l'ai codé, ce bout là!!

darklord22

damn!

benou :gun: :gun: :gun:

:D

bien vu :fou:

benou

gfive a écrit a écrit :

Effectivement, y'a un yield, là dedans!! :D

victoire !! :) :D :lol:

gfive

Mais pourquoi tu veux pas écrire et écouter en même temps sur ta socket??? 8[
Pasque sinon, le bout de mon client qui marche nickel (c'est un bout du client du nouveau chat Orange!! :D (à voir là : chat.orange.fr)

Le début :

public Client(String ip, int port) throws IOException {
socket = new Socket(ip, port);
reader = new BufferedReader(new InputStreamReader(server.getInputStream()));
writer = new PrintWriter(new OutputStreamWriter(server.getOutputStream()), true);
thread = new Thread(this);
thread.setPriority(Thread.NORM_PRIORITY);
thread.start();
}

la méthode run()

public void run() {
String line;
while (thread != null) {
try {
if ((line = reader.readLine()) != null) {
try {
Message msg = MessageFactory.getMessage(line);
msg.anwser(parent);
} catch (MessageFormatException mfe) {
// gestion...
}
} else {
fireEvent(NetworkEvent.SERVERDIED);
}
} catch (IOException ioe) {
fireEvent(NetworkEvent.SERVERDIED);
}
thread.yield();
}

Et la méthode send :

public void send(String msg) {
writer.println(msg);
writer.flush();
}
}

Côté serveur, c'est un peu plus complexe :

l'objet ServerSocket instancie un objet Runnable pour gérer la Thread, mais le run et le send sont similaires à ceux là....

Effectivement, y'a un yield, là dedans!! :D

benou

nan yield ca rend le main, mais ca arrête pas le thread ...
ca laisse juste les autres thread s'excuter.
ex :

While (true) {
Thread.yield();
}

ca ce ne sera pas bloquant : les autres thread fonctionneront encore !
D'ailleur, je pense qu'avant de se mettre en pause, le sleep() appelle le yield()

darklord22

benou a écrit a écrit :

:??: pkoi ?? ca revient au même que toi sauf que ca ne freeze pas le thread pdt 2 sec.
ou bien y a un truc qui m'échappe ...

bin tu yeld donc il faut bien que on te réveille non? si le notify se crashe chze moi, le thread se réveillera de toutes façons au bout de 2 sec

si je faisais this.wait();

ce serait pareil que ta solution :D

benou

darklord22 a écrit a écrit :

tu risques d'avoir des probs de deadlock là.

:??: pkoi ?? ca revient au même que toi sauf que ca ne freeze pas le thread pdt 2 sec.
ou bien y a un truc qui m'échappe ...

darklord22

axel5 a écrit a écrit :

ok merci, je vais voir tout ca...
pour ce qui est du thread, c'est la seule solution que j'ai
trouvé, sachant que le thread parent gere la connection principale (d'ou le synchronized, histoire de ne pas send n'importe quand)... le pb c'est que je suis obligé de faire un appelle bloquant sur l'ecoute du client pour pouvoir detecter sa deconnection (et donc killer le process), mais en mm temps, il faut je puisse envoyer a cette mm connection des messages quand ils arrivent... voila le pourquoi du comment, j'espere que c'etait clair

pas du tout. SI tu veux voir si la connec est bonne tu peux implémenter un protocole très simple, le ping pong. Ton servoir envoie un ping et si après un temps donné tu ne recois pas de pong tu considère que ton clien est down.

axel5

ok merci, je vais voir tout ca...
pour ce qui est du thread, c'est la seule solution que j'ai
trouvé, sachant que le thread parent gere la connection principale (d'ou le synchronized, histoire de ne pas send n'importe quand)... le pb c'est que je suis obligé de faire un appelle bloquant sur l'ecoute du client pour pouvoir detecter sa deconnection (et donc killer le process), mais en mm temps, il faut je puisse envoyer a cette mm connection des messages quand ils arrivent... voila le pourquoi du comment, j'espere que c'etait clair

darklord22

benou a écrit a écrit :

je persiste : si tu ne souhaite pas bloquer ton thread, fais un yield !

Citation :

public static void yield()
Causes the currently executing thread object to temporarily pause and allow other threads to execute.

tu risques d'avoir des probs de deadlock là. En fait tout dépend des requierments du systeme. Avec ma solution par exemple, il fait un test toutes les deux sec en inactivités ce qui n'est pas méchant.

Et il y a un notify qui enclence une InterruptedException dès que tu ajoutes un message donc c'est relativement correct.

Maintenant faut pas utiliser ton thread pour autre chose que ca ;)

benou

je persiste : si tu ne souhaite pas bloquer ton thread, fais un yield !

Citation :

public static void yield()
Causes the currently executing thread object to temporarily pause and allow other threads to execute.

darklord22

Voila une solution qui fonctionne très bien chez moi.

D'une part tu as ton thread qui contient un vecteur v

Code :

public void run() {
while (not_finished) {
while (v.size() != 0) {
// faire qqch avec v[i]
// remove v[i]
}
try {
synchronised(this) {
wait(2000);
}
}
catch (InterruptedException ie) {
// new message in the queue
}
}
}

et d'autre part tu as une méthode pour ajouter des messages

Code :

public synchronised void addMessage(Message msg) {
v.add(msg);
notify();
}

and it works perfectly baby ;)

Dis moi si ca t'aide ...

Rawhead rex

Tu pourrais peut-etre aussi gagner en bufferisant l'affichage plutot qu'effectuer un "System.out.println"(je crois que cette fonction ne rend pas la main au thread principal tant qu'elle n'a pas finit)
Tu devrais gagner en fluidite.

gfive

D'un autre côté, utiliser un Thread pour ça, ça me paraît douteux : utiliser un thread pour écouter une socket, d'accord, mais après...8|....je te suis pas! :D

Il sert à quoi, exactement, ton vecteur???

benou

rajoute un Thread.yield() dans ta boucle : ca rend la main au système.
c'est indispensable.

Le thread.sleep() fonctionne aussi mais endoer ton thread pdt le temps que tu as définie, ce qui n'est pas forcément ce que tu souhaites.

axel5

voila en gros ce que fait le run() du thread:

while(m_stop == false)
{
if (m_answer.isEmpty() == false)
{
synchronized(m_parentJob)
{
String ans = (String)m_answer.firstElement();
System.out.println("Answer manager " + m_id + " > " + ans);
outToClient.print(ans);
m_answer.remove(ans);
}
}
}

m_answer est un vecteur, et outToClient... enfin c assez explicite :wahoo:

Cherrytree

Dans ton Thread, il faut absolument qu'à un moment donné tu fasses :

Thread monThread;
...
monThread.sleep(leTempsQueJeVeux);

où leTempsQueJeVeux est un entier en millisecondes (à vérifier pour l'unité).

gfive

Un bout de code?????

axel5

Bonjour

j'ai un probleme d'occupation cpu pour une application
réseau. cette derniere crée un thread qui boucle
à l'infini pour envoyer des messages qu'on lui donne...
le probleme est que cette boucle entraine une utilisation
maximale des ressources cpu, alors qu'on aimerait avoir un
comportement plus proche d'un daemon, ou encore d'un
procédé de callback comme pour les i/o...
y-a-t-il une solution, spécifique java ou non ?