Discussion :

[Gaspard22]

Bonjour,

j'ai crée une application qui communique avec une application cliente via socket et qui recoit du xml et qui en renvoi.

Mon appli est elle meme cliente d'une autre appli qui lui fournit l'information idoine.

Dans l'ensemble tout marche sans problème, sauf qu'une méthode me renvoi mon xml dans l'outputstream de la socket en décalé.
En détail j'utilise ma méthode, qui créé un doc xml, qui une fois créé l'insère dans le flux de ma socket pour le remonter au client.
Sur la deuxième utilisation le flux me remonte le premier doc Xml.

En essayant d'analyser de plus près , et en inscrivant juste une String , celle ci était remontée immédiatement.
En lui imposant un Thread.sleep(1000) , cette chaine était remontée dans un deuxième utilisation.

J'ai beau avoir fait des flush pour declencher une action dans le flux, ça ne marche pas.
Je ne vois pas comment faire et cela devient urgent !!
Merci de m'aider

[thelvin]

Pas bien expliqué. On est pas dans ta tête.

[Gaspard22]

reexplication

J'ai 3 modules, 1 module A qui est serveur socket d'un module B et client socket d'un module C.

Le module B envoi une requête via un flux xml, au module A. Celui ci créé les objets et demande des infos complémentaires au module C dans un deuxième temps. Une fois tous les traitements métier exécutés, le module A renvoi dans le outputstream de la connexion ouverte précédemment entre A et B, la réponse sous format d'un document xml à B.

le problème est que ma réponse ne remonte pas dans l'outpustream à la première exécution, mais lorsqu'on exécute l'action une deuxième fois. Et lors du troisième passage, j'obtiens la réponse de ma deuxième demande.

En testant je me suis rendu compte que le temps de traitement de mon action entre le module B et C pourrait être en cause, mais je ne vois pas pourquoi précisément.

Je peux fournir le code pour plus de détails bien sur

[thelvin]

Je peux fournir le code pour plus de détails bien sur

Ben, oui -_-°. Il n'y a pas de raison bien connue et habituelle pour que cela arrive.

À mon avis, ça doit être en rapport avec la manière dont tu sépares plusieurs requêtes dans ton module A.
Si je voulais faire un exemple en quelques lignes, l'un des points clé serait que les modules A et B, quand ils s'envoient des documents XML, doivent indiquer leurs tailles en octets. Puis de lire exactement ce nombre d'octets pour construire le XML.
Mais tout dépend comment tu t'y prends.

[Gaspard22]

je fournis le code lundi, mais en substance

le client envoie un flux xml ayant une requête, avec un content
je traite cette "requête".
Je créé un document xml en réponse et je le passe à une méthode de renvoi

cette méthode a comme paramètre la Socket initialisée à la connexion du client

j'utilise 2 méthodes

methode XMLOutputter.output(Document, Socket.OuputStream);

et un Writer attaché au même OutputStream.

Lorsque j'utilise le writer seul sans passer de doc, j'ai une réponse immédiate, lorsque j'utilise le writer et lui impose une pause d'1 seconde, la réponse n'arrive qu'après une deuxième appel.

[thelvin]

Lorsque j'utilise le writer seul sans passer de doc, j'ai une réponse immédiate, lorsque j'utilise le writer et lui impose une pause d'1 seconde, la réponse n'arrive qu'après une deuxième appel.

Attention tu repars dans le vague, là. Cette histoire d'imposer une seconde n'est pas claire.

[Gaspard22]

la seconde d'attente est un test pour savoir, si c'est le temps de réaction ou le fait de passer un doc xml qui provoque ce pb.

et donc je pense que c'est le temps de réponse qui pose pb, mais je ne vois pas trop pourquoi

[thelvin]

la seconde d'attente est un test pour savoir, si c'est le temps de réaction ou le fait de passer un doc xml qui provoque ce pb.

et donc je pense que c'est le temps de réponse qui pose pb, mais je ne vois pas trop pourquoi

Humm. Je voulais dire que sans voir le code on peut pas en déduire grand-chose, et que tu t'y prends sûrement différemment pour juste renvoyer une String ou bien attendre une seconde puis ensuite renvoyer une String.

Mais en y réfléchissant, c'est peut-être juste le module A qui fait n'importe quoi, et qui ne s'intéresse plus à la réponse après un certain délai. Seulement "ne s'intéresse plus" ça peut vouloir dire "ne cherche plus à lire la prochaine réponse" et qu'il ne le fera que la prochaine fois qu'il envoie une requête, pensant que la réponse qui arrive est pour cette nouvelle requête (alors qu'en réalité c'est la réponse à la précédente requête, celle qu'il n'a pas voulu lire.)
Ce n'est pas un comportement normal, mais il pourrait y avoir un bug de ce genre.

[Gaspard22]

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
public void CPS (String commande, String protocole){
 
		try {
			HashMap<String, Object> uneRep= new HashMap<String, Object>();
			currentDocu = buildDoc(protocole,commande);
			TransformationHandling handlresp = new TransformationHandling();
			uneRep = handlresp.FluxPlatToObject(commande, protocole);
			praticInst = new PraticienIntermediaire();
 
			for (Map.Entry e : unerep.entrySet()) {
				if(((String) e.getKey()).equalsIgnoreCase("CPS")){
				praticInst = (PraticienIntermediaire) e.getValue();
				}
			}
				ArrayList<Element> PratEle =buildingPraticien(praticInst);
				for (Element elm : PratEle){
 
					praticien.addContent(elm);
 
				}	
 
 
				SendCodeOut(currentDocu);
 
		} catch (Exception e) {
 
			currentDocu = ErrorDoc("Erreur Com",protocole,commande, "-6666");
e.printStackTrace();
		}

Première méthode qui créée les objets et envoi le document créé.

[Gaspard22]

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
private void SendCodeOut(Document doc){
		try {
 
 
		Format iso;
		XMLOutputter outputter = new XMLOutputter();
		iso = outputter.getFormat();
	    iso.setEncoding("iso-8859-1");
		outputter.output(doc, sock.getOutputStream());
		sock.getOutputStream().flush();
// rajoute un point final
		Writer writer = new OutputStreamWriter(sock.getOutputStream());
		writer.write("\r\n.\r\n");
		writer.flush();
 
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
}

sock est initialisé dans le constructeur.

[Gaspard22]

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
47
48
public class ConnectionSocket implements Runnable
{
	public static Socket client;
	public XmlToObject tto;
	public static OutputStream Fluxout;
	public boolean close = false;
	private static SocketGenerateur demanderInfo;
 
	public ConnectionSocket(Socket sClient)
	{
		client = sClient;
 
	}
 
	public void run()
	{
 
		System.out.println("Connecté");
 
		while(!close)
		{
 
			try
			{
				Cmain.setConnect(true);
				Fluxout= client.getOutputStream();
				tto.FluxVersObjet(client.getInputStream());
				//Objet de reponse de l'application qui sort en OutputStream
 
//					// On transmet le socket client pour la réponse 
					ObjectsToXml stdal = new ObjectsToXml(client);
					stdal.CPS(tto.getCurrentCommande(), tto.getProtocole());
	} catch (XMLStreamException e) {
				Cmain.setConnect(false);
				close = true;
			} catch (InterruptedException e) {
				Cmain.setConnect(false);
				close = true;
			} catch (IOException e) {
				Cmain.setConnect(false);
				close = true;
			} catch (Exception e) {
				Cmain.setConnect(false);
				e.printStackTrace();
				close = true;
			}
 
		}

Ma classe de connexion du client socket

[thelvin]

Il vaudrait peut-être quand même mieux simplifier le code, là. Il y a trop d'inconnues. De plus, je croyais qu'il suffisait d'attendre une seconde, pour avoir le problème ? Alors autant regarder le code de ça.

Sinon, je répète que l'erreur pourrait très bien être du côté du module B qui ferait n'importe quoi dès que la réponse tarde à arriver. Il faudra donc regarder ça aussi.

[Gaspard22]

En effet, je suis désolé, le code est un peu long et encore j'ai raccourci

mais en effet, en faisant abstraction de l'xml, le temps de réponse exigé est immédiat, et je ne vois pas comment retarder ce temps de réponse, surtout que le traitement pour obtenir l'xml est un peu long.

Mettre le traitement dans un Thread ?

[Gaspard22]

une indication supplémentaire, je n'ai aucun problème de remontée lorsque j’exécute le programme sous mac.

[Gaspard22]

En googlisant un peu j'ai vu qu'il existait des sockets Asynchrones avec Java NIO, serait ce une solution possible ?

[thelvin]

En googlisant un peu j'ai vu qu'il existait des sockets Asynchrones avec Java NIO, serait ce une solution possible ?

Le problème dont tu nous parles n'existe pas pour l'instant. On ne peut donc pas vraiment te suggérer de solution.

Si tu pouvais nous montrer le problème, on pourrait certainement lui trouver une solution plus simple que les sockets asynchrones (qui servent surtout à mieux passer à l'échelle quand on a beaucoup de connexions réseau.)

[Gaspard22]

En effet , les sockets asynchrones ne sont d'aucune utilité vu que je traite une seule connexion à la fois.

Sinon mon problème se résume a savoir pourquoi dès que je fais un traitement un peu long, l'OutputStream de la socket ne renvoie plus rien. Je peux te proposer d'envoyer mon appli en entier, mais ça fait quelques Mo.

Ou alors dis moi ce qu'il te manque pour que soit plus clair

et merci de bien vouloir m'aider au fait

[thelvin]

Comme je te l'ai déjà dit, au vu des symptômes, j'ai plutôt l'impression que c'est le module B, celui qui est censé lire la réponse, qui fait n'importe quoi.
Donc ce serait plutôt son code à lui qui m'intéresserait.

Sinon, concernant ce qu'on a besoin, ben tu es dans le même cas que tout le monde, tout le temps :

Il faut un tout petit programme, minuscule, aussi petit que possible, et qui :
- peut être lancé et testé sans configuration ni fichier annexe
- a le problème que tu as
- ne fait que ce qui est nécessaire pour avoir le problème, et absolument rien d'autre

En l'occurrence, vu que tu as un problème de communication entre deux programmes, il vaudrait mieux deux petits programmes, plutôt qu'un.

Autrement dit, ton premier travail est d'isoler le problème : enlever tout ce qui ne provoque pas le problème, et ne garder que ce qui le provoque.
En réalité, en général on s'en sort très bien tout seul quand on a fait ça. Nous sommes là au cas où ce ne soit pas le cas, mais ça ne sert à rien de venir avant.

[Gaspard22]

J'ai réduit l'application a 6 classes, en simulant un délai pour reproduire le pb.
il y a juste le module A qui une appli en 4D, toute faite.

Est ce que ça t’intéresses toujours ?

[thelvin]

Ben, pas trop -_-°.

Moi pour lire un message sur une socket, puis lui répondre après une seconde, je n'ai pas besoin de 6 classes. Ce serait plutôt 36 lignes...

Par ailleurs, s'il y a une appli toute faite dont tu ne maîtrises pas le code, et qu'elle n'a pas le problème sur toutes les plate-formes, alors c'est sûrement elle la fautive, évidemment -_-°...
Nous n'allons pas deviner s'il existe un moyen de la convaincre d'attendre plus d'une seconde. Il faudrait plutôt en parler avec les gens qui ont fait cette application.