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 ;
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TestMan
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
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.
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
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
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.
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
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
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é ...
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
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.
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.
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
On 29 juil, 11:08, steph wrote:
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 ?
On 29 juil, 11:08, steph <st...@nowhere.net> wrote:
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 ?
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
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 wrote:
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 ?
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 <st...@nowhere.net> wrote:
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 ?
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 wrote:
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
On 2 août, 10:11, Jean-Marie wrote:
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 wrote:
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/
On 2 août, 10:11, Jean-Marie <j...@noemail.fr> wrote:
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 <st...@nowhere.net> wrote:
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/
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 wrote:
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
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 wrote:
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 ?
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 <st...@nowhere.net> wrote:
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 ?
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 wrote:
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 ?
