Ca dépend. Ca peut avoir un interet dans ton archi (des IO bloquantes avec un client par thread sont une option parmi d'autres) mais ca peut aussi être un exercice imposé. Par exemple vouloir monitorer stdout/stderr d'un paquet de processus, Java te retournant un stream qui n'est pas un selectable channel tu dois avoir 2 ou 3 threads par processus monitorés ca monte très vite... De même un pauvre service RMI qui se prend un pic de charge ponctuel, ca arrive vite.
Dans tout les cas vouloir tirer des généralités sur des performances d'une application non définie sur une architecture non définie avec une workload non définie me laissera toujours dubitatif. Y'a des avantages et des inconvénients à beaucoup de choses...
[^] # Re: En clair
Posté par ckyl . En réponse au journal Vente liée : comment se tirer soi-même une balle dans le pied. Évalué à 6.
Ca dépend. Ca peut avoir un interet dans ton archi (des IO bloquantes avec un client par thread sont une option parmi d'autres) mais ca peut aussi être un exercice imposé. Par exemple vouloir monitorer stdout/stderr d'un paquet de processus, Java te retournant un stream qui n'est pas un selectable channel tu dois avoir 2 ou 3 threads par processus monitorés ca monte très vite... De même un pauvre service RMI qui se prend un pic de charge ponctuel, ca arrive vite.
Dans tout les cas vouloir tirer des généralités sur des performances d'une application non définie sur une architecture non définie avec une workload non définie me laissera toujours dubitatif. Y'a des avantages et des inconvénients à beaucoup de choses...