Discussion :

[powel]

Bonsoir à tous,

prenons cet extrait de début de code :

Code :

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

1
2
3
 
final Socket socket = new Socket (hostName, port);
is = socket.getInputStream ();

j'ai besoin qu'au moins deux threads traitent les infos du flux "is" genre :

Code :

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

1
2
3
4
5
6
final Scanner scan = new Scanner(is, "UTF-8");
 
				while (scan.hasNextLine()) {
...
 
}

chaque thread prend ce qu'il a besoin comme infos et effectue des actions en conséquence.

Problème ; lorsque l'un thread lit une ligne d'is en quelque sortes il l'enlève à l'autre thread qui lit la suivante et qui a à son tour l'enlève à l'autre.

Or j'aimerai que tous les threads aient à disposition toutes les infos d ' "is".

Donc est-il possible de dupliquer le flux "is" afin que chaque thread possède le même flux ...

Pour le moment j'ai du me faire un distributeur du flux avec des pools :

Code :

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

1
2
3
4
5
6
7
 
while (scan.hasNextLine()) {
					final String line = scan.nextLine();
					for (int i = 0; i < listeners.size(); i++) {
						listeners.get(i).queue.add(line);
					}
}

Dans ce code, il y a autant de listeners que de thread ce qui me permet d'imiter une duplication des flux.


Mais est-ce une méthode normale je vois que Java ne propose rien quand à une duplication du flux d'entrée ou j'ai mal regardé ?

Merci.

[thelvin]

Hello,

Disons qu'il est surtout extrêmement bizarre d'avoir ce besoin-là.

Si l'un de tes threads s'occupe de consommer les données, pourquoi diable d'autres threads devraient-ils s'en occuper ? Un prédécoupage en messages individuels, qui peuvent être ensuite envoyés à tous les observateurs, ça peut encore se comprendre. Mais l'InputStream directement.... Pourquoi ?

A ma connaissance Java ne propose pas de duplication de flux, mais il existe des bibliothèques tierces qui le font. Probablement pas pour les gens qui penseraient à une chose pareille, toutefois.

[powel]

Bon voilà qui répond à ma question, ma solution surprend donc.

L'idée est qu'une fois connecté à un hôte, je puisse lancer toutes sortes de listener de courtes ou longues durées, par exemple pour récupérer ponctuellement des infos après une demande, ou un listener permanent qui sert à répondre présent à l'hôte.

Chaque listener ne prend dont ce qu'il a besoin et sans enlever à son voisin ce que lui a besoin.

Sachant que l'hôte n'a pas d'ordre de règles quand à l'envoie des messages ;
- il peut très bien envoyer une longue liste durant jusqu'à 1 minute
- pendant ce temps il demande si le client est toujours présent (réponse à un ping, il entre coupe donc sa liste)
- et dans le même temps m'avertir par petites touches d'événements ponctuels

Imaginons donc trois listener, chaqu'un traite son taf, s'éteind lorsqu'il a finit. etc ...

---

ma soluce marche mais c'est vrai que ça fait un moment que je trouve bizarre de l'avoir fait artisanalement.

[thelvin]

Disons que ça paraît plus logique de s'abstraire des InputStreams et de raisonner par messages, avec les listeners, comme tu as déjà.

[powel]

OK

Entre-temps j'ai fait un truc rapide.

Donc à quoi peut me servir de dupliquer un flux d'entrée ? pour éviter ça ...

[thelvin]

Oui mais c'est ce que je viens de dire en fait. Ne duplique pas le flux d'entrée.
Lis les lignes du flux d'entrée, et envoie-les toutes aux concernés.

[powel]

Donc ma soluce n'est pas bizarre au final ... courante même dans d'autres contextes ?

[thelvin]

Je t'avoue que je connais pas d'exemple, mais a priori ça peut s'imaginer.

[powel]

Il n'empêche que même en remaniant mon client pour le rendre plus simple et tant pis si moins efficace, je tombe toujours sur la même conclusion que dupliquer mon InputStream me simplifierai bien des problèmes.

Pour ceux que ça intéresse :
https://stackoverflow.com/questions/...an-inputstream

Lui se prend pas la tête et copie carrément des blocs d'octets.
Comme moi j'ai des lignes ASCII à traiter, je me suis fait des threads de pools de lignes dupliquables à volonté.

Lui a un autre besoin, mais en tous cas être confronté au besoin ne semble pas être mon cas unique et pas non plus une bizarrerie.

[thelvin]

Faudrait savoir, c'est la même chose ou pas la même chose ?

En l'occurrence, ça l'est pas. Lui il a pas de thread. Il a besoin de faire une première chose avec son InputStream, et après que cette première chose soit terminée, d'en faire une deuxième.

- besoin du truc deux fois, pas trois, pas quatre, pas autre chose que deux.
- pas de thread. Une première étape, suivie d'une deuxième quand la première est terminée.

Absolument rien à voir donc.

En plus son raisonnement est ridicule, clairement il fait comme si l'informatique c'était magique.

Dans ton cas on peut pas trop savoir, tu nous as juste parlé de threads et de listeners. On peut envisager des raisons logiques.

[powel]

En tous cas je suis content ; en affinant mon analyse je n'ai finalement plus besoin que d'UN seul thread qui attend en permanence l'InputStream, se charge de décoder les lignes selon le protocole et les distribue dans une liste de 1 à n objets de type "Events" dont l'appelant à tout le loisir de charger pour donner un comportement au client.

Je m'aperçois donc que je n'ai pas besoin de plusieurs listeners qui faisaient donc un travail partiellement redondant puisqu'ils se chargeaient de décoder le protocole et d'enclencher les événements. Alors qu'en fait c'est juste le nombre et la nature d'événements qui est variable, le protocole peut être décodé une seule fois.

ça parait tout con à dire, mais quand on a la tête dans le guidon, on le voit pas de suite ; on fonce à coder des listeners Thread pour être tranquille.

Mon code est carrément simplifié et les choses se structurent d'elles-même.

Et surtout je m'éloigne de ma problématique de vouloir dupliquer l'InputStream que Java ne propose pas de base et ça a un côté rassurant

-----

Cela dit, même après une 3éme 4éme version de mon client, remaniements et autres, j'en arrive à douter de mes certitudes et mes solutions. Je fais même volontairement le contraire pour confirmer ma solution de départ.

Et il faut aller loin jusqu'à s'interroger pourquoi il n'était pas naturel à Java de proposer une duplication du flux d'entrée.

-----

Donc si je me mets volontairement moi-même en doute, tu comprendras qu'il n'est pas anormal que j'émette un doute des propos d'un autre même si celui-ci m'a pourtant très pédagogiquement mit sur la voie à propos des classes anonymes.

-----

Quand à StackOverflow, je maintiens qu'il n'est pas le seul à s'être interrogé sur la question et il y a d'autres forums de progs où d'autres se sont interrogés.

Ce n'est pas parce qu'une solution est ignorée 9 / 10 par la masse, qu'il n'y a pas une fois où l'on aura pas d'autres choix que de s'y intéresser.