write non bloquant

Le
Jean-Marie
Bonjour

j'écris une même information vers 3 sockets différents, associés donc à
3 applications qui attende cette information ;
quand le débit de transfert est élévé par rapport au temps de traitement
de l'information par ces application, il se produit un blocage en
écriture (j'utilise le write de OutputStream) tant que le canal tcp/ip
est "plein" ; comme la diffusion est séquentielle et que le write est
bloquant il suffit qu'une seule application soit lente dans son
traitement pour pénaliser les 2 autres ;
ce que je souhaite est d'éviter cette pénalisation ; autrement dit
je voudrai faire un write non bloquant qd le canal tcp/ip est "plein" ;
mais je n'ai pas trouvé comment faire ;

si qn peut m'aiguiller

merci

Jean-marie
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
TestMan
Le #229572
Bonjour

j'écris une même information vers 3 sockets différents, associés donc à
3 applications qui attende cette information ;
quand le débit de transfert est élévé par rapport au temps de traitement
de l'information par ces application, il se produit un blocage en
écriture (j'utilise le write de OutputStream) tant que le canal tcp/ip
est "plein" ; comme la diffusion est séquentielle et que le write est
bloquant il suffit qu'une seule application soit lente dans son
traitement pour pénaliser les 2 autres ;
ce que je souhaite est d'éviter cette pénalisation ; autrement dit
je voudrai faire un write non bloquant qd le canal tcp/ip est "plein" ;
mais je n'ai pas trouvé comment faire ;

si qn peut m'aiguiller

merci

Jean-marie


Bonjour,

Si c'est la même information à envoyer sur plusieurs sources, la
multidiffusion me semble la plus indiquée.

Regardez JGroups par exemple :
http://www.jgroups.org/

Si vous avez besoin de souplesse, je vous indiquerez clairement de
passer par du JMS et de choisir pour l'instant une implémentation qui
permet d'utiliser la multidiffusion IP par exempel
http://sourceforge.net/projects/mantaray

Ainsi, lorsque le besoin s'en fera ressentir, vous pourrez basculer vers
tout autre implémentation sans grand impact pour votre appli.

A+
TM

Jean-Marie
Le #229512
Bonjour

est-c'que les classes du package java.nio.channels
n'apportent pas une solution à ce problème ;
elles permettent de créer apparemment des sockets
non bloquants et donc je pense de faire des écritures
non bloquantes

jean-Marie

Bonjour

j'écris une même information vers 3 sockets différents, associés donc
à 3 applications qui attende cette information ;
quand le débit de transfert est élévé par rapport au temps de traitement
de l'information par ces application, il se produit un blocage en
écriture (j'utilise le write de OutputStream) tant que le canal tcp/ip
est "plein" ; comme la diffusion est séquentielle et que le write est
bloquant il suffit qu'une seule application soit lente dans son
traitement pour pénaliser les 2 autres ;
ce que je souhaite est d'éviter cette pénalisation ; autrement dit
je voudrai faire un write non bloquant qd le canal tcp/ip est "plein" ;
mais je n'ai pas trouvé comment faire ;

si qn peut m'aiguiller

merci

Jean-marie


Bonjour,

Si c'est la même information à envoyer sur plusieurs sources, la
multidiffusion me semble la plus indiquée.

Regardez JGroups par exemple :
http://www.jgroups.org/

Si vous avez besoin de souplesse, je vous indiquerez clairement de
passer par du JMS et de choisir pour l'instant une implémentation qui
permet d'utiliser la multidiffusion IP par exempel
http://sourceforge.net/projects/mantaray

Ainsi, lorsque le besoin s'en fera ressentir, vous pourrez basculer vers
tout autre implémentation sans grand impact pour votre appli.

A+
TM



TestMan
Le #229478
Bonjour

est-c'que les classes du package java.nio.channels
n'apportent pas une solution à ce problème ;
elles permettent de créer apparemment des sockets
non bloquants et donc je pense de faire des écritures
non bloquantes



Bonsoir,

Il me semble que la réponse est dans votre question :o)

Je rajouterai que l'avantage de la multidiffusion (multicast IP) par
rapport aux nio, c'est de ne nécessiter qu'un seul flux quelque soit le
nombre de recepteur.

En utilisant un couche type JGroups par dessus, vous allierez cet
avantage à celui de la qualité de service apportée par TCP.

En clair, on délivre à coup sûr et le plus tôt possible avec un coup
réseau le plus faible possible. Et je rajouterais qu'à programmer, il
n'y a pas photo en terme de simplicité ...

Alors : « Que veux le peuple ? » ;-)

A+
TM

steph
Le #229426
Jean-Marie wrote:
Bonjour

j'écris une même information vers 3 sockets différents, associés donc à
3 applications qui attende cette information ;
quand le débit de transfert est élévé par rapport au temps de traitement
de l'information par ces application, il se produit un blocage en
écriture (j'utilise le write de OutputStream) tant que le canal tcp/ip
est "plein" ; comme la diffusion est séquentielle et que le write est
bloquant il suffit qu'une seule application soit lente dans son
traitement pour pénaliser les 2 autres ;
ce que je souhaite est d'éviter cette pénalisation ; autrement dit
je voudrai faire un write non bloquant qd le canal tcp/ip est "plein" ;
mais je n'ai pas trouvé comment faire ;

si qn peut m'aiguiller

merci

Jean-marie


Bonjour,

Dans ton cas je te recommanderai de déléguer l'écriture à d'autres
threads, une par application, couplées à des pipes.

Chaque thread d'application lit dans son pipe et écrit sur sa socket.
La thread principale effectue les traitements puis écrit dans les pipes.

Il faudra juste être vigilant à la taille des buffers des pipes car
d'après ce que tu décrits, une des applications ne le viderait pas assez
vite.

Cette solution est efficace si tu dois lisser une charge dans le temps:
des piques de charges mais une charges moyenne inférieure à la puissance
de traitement de l'application la plus faible.
Par contre, si tu a une forte charge constante, supérieur à la puissance
de traitement d'une des tes applications clientes, ce ne réglera rien.

ToOmS
Le #229381
On 29 juil, 11:08, steph
Dans ton cas je te recommanderai de déléguer l'écriture à d'autres
threads, une par application, couplées à des pipes.

Chaque thread d'application lit dans son pipe et écrit sur sa socket.
La thread principale effectue les traitements puis écrit dans les pipes.

Bonjour,


Etant donné que le contenu à écrire est le même, je ne vois pas
l'intérêt final des pipes multithreadés, par rapport à JMS.
On n'est plus bloqué, mais on dépense de l'énergie à coder qq chose de
moins lisible, non ?

Jean-Marie
Le #229375
Bonjour

je suis d'accord avec toi ; j'ai utilisé finalement la librairie
java.nio et çà fait ce que je souhaite à savoir ne pas bloquer
sur une écriture pour ne pas pénaliser d'autres récepteurs
en attente de la même information ; si les récepteurs sont trop lents
à traiter l'information c'est à eux d'optimiser le traitement ;
de plus, dans mon contexte, cette situation "d'engorgement"
n'est envisagé que sur un plan théorique ; elle ne devrait pas se
produire ou du moins très rarement ;
je continue donc avec la même logique qu'avant à savoir une écriture
séquentielle vers plusieurs récepteurs ;
KIS : Keep It Simple (autant que possible)

jean-marie


On 29 juil, 11:08, steph
Dans ton cas je te recommanderai de déléguer l'écriture à d'autres
threads, une par application, couplées à des pipes.

Chaque thread d'application lit dans son pipe et écrit sur sa socket.
La thread principale effectue les traitements puis écrit dans les pipes.

Bonjour,


Etant donné que le contenu à écrire est le même, je ne vois pas
l'intérêt final des pipes multithreadés, par rapport à JMS.
On n'est plus bloqué, mais on dépense de l'énergie à coder qq chose de
moins lisible, non ?




ToOmS
Le #229374
On 2 août, 10:11, Jean-Marie
Bonjour

je suis d'accord avec toi ; j'ai utilisé finalement la librairie
java.nio et çà fait ce que je souhaite à savoir ne pas bloquer
sur une écriture pour ne pas pénaliser d'autres récepteurs
en attente de la même information ; si les récepteurs sont trop lents
à traiter l'information c'est à eux d'optimiser le traitement ;
de plus, dans mon contexte, cette situation "d'engorgement"
n'est envisagé que sur un plan théorique ; elle ne devrait pas se
produire ou du moins très rarement ;
je continue donc avec la même logique qu'avant à savoir une écriture
séquentielle vers plusieurs récepteurs ;
KIS : Keep It Simple (autant que possible)

jean-marie




On 29 juil, 11:08, steph
Dans ton cas je te recommanderai de déléguer l'écriture à d'au tres
threads, une par application, couplées à des pipes.

Chaque thread d'application lit dans son pipe et écrit sur sa socket.
La thread principale effectue les traitements puis écrit dans les pi pes.


Bonjour,

Etant donné que le contenu à écrire est le même, je ne vois pas
l'intérêt final des pipes multithreadés, par rapport à JMS.
On n'est plus bloqué, mais on dépense de l'énergie à coder qq c hose de
moins lisible, non ?- Masquer le texte des messages précédents -


- Afficher le texte des messages précédents -


Au cas où, pour ceux qui suivent : http://gfx.developpez.com/tutoriel/jav a/nio/



Jean-Marie
Le #230050
autres liens utiles:
http://www.exampledepot.com/egs/java.nio/NbClientSocket.html
http://www.google.com/search?q=Java+NIO+tutorial
http://www.ibm.com/developerworks/library/j-perf03174.html
et petite remarque importante sur ByteBuffer.allocateDirect :
http://www.groupsrv.com/computers/about36352.html

Bonjour

je suis d'accord avec toi ; j'ai utilisé finalement la librairie
java.nio et çà fait ce que je souhaite à savoir ne pas bloquer
sur une écriture pour ne pas pénaliser d'autres récepteurs
en attente de la même information ; si les récepteurs sont trop lents
à traiter l'information c'est à eux d'optimiser le traitement ;
de plus, dans mon contexte, cette situation "d'engorgement"
n'est envisagé que sur un plan théorique ; elle ne devrait pas se
produire ou du moins très rarement ;
je continue donc avec la même logique qu'avant à savoir une écriture
séquentielle vers plusieurs récepteurs ;
KIS : Keep It Simple (autant que possible)

jean-marie


On 29 juil, 11:08, steph
Dans ton cas je te recommanderai de déléguer l'écriture à d'autres
threads, une par application, couplées à des pipes.

Chaque thread d'application lit dans son pipe et écrit sur sa socket.
La thread principale effectue les traitements puis écrit dans les pipes.

Bonjour,


Etant donné que le contenu à écrire est le même, je ne vois pas
l'intérêt final des pipes multithreadés, par rapport à JMS.
On n'est plus bloqué, mais on dépense de l'énergie à coder qq chose de
moins lisible, non ?






Publicité
Poster une réponse
Anonyme