Discussion :

[Callimard]

Bonjour à tous!

Je suis en train de faire un serveur RMI et je voulais justement savoir comment le système RMI géré les threads.

En faisant quelques teste j'ai découvert que:
- chaque client à sa thread propre par port, c'est-à-dire que pour chaque RemoteObject exporté sur un même port, les méthodes appelées du client sur ces objets seront exécutées dans une même thread spécifique au client.
- chaque objet exporté sur des ports différents seront exécutés sur des threads différentes. Ex: le client C1 demande l'objet o1 qui est sur le port 35 et l'objet o2 qui est sur le port 40, les méthodes de o1 seront exécutées sur une thread différente de celle qui exécutera les méthodes de o2. Cependant si un objet o3 est exporté sur le même port que o2, alors si le client C1 exécute des méthodes de o3, alors elles seront exécutées sur la même thread que o2.

Piouf, si mes testes sont bons ce que je dis est normalement vrai. Cependant je vous explique tout ça pour vous dire que moi ça ne me convient pas, je n'aime pas le fait que pour chaque client il y est au moins une thread qui soit créée.

Du coup je voudrais savoir s'il existe une possibilité pour "configurer" le RMI pour qu'il ne puisse pas créer une thread par client mais les regrouper dans la même thread ou un pool de thread.

Je vous remercie d'avoir lu mon message, j'espère que vous pourrez m'orienter vers quelque chose!

Merci beaucoup!

Callimard

[Gugelhupf]

Bonsoir,

J'imagine que tu souhaites conserver le même numéro de port pour les services (cf : o1, o2, o3) exposés à travers RMI pour éviter les problèmes réseaux, le problème est que tu penses surement qu'avoir un seul thread pour gérer tous les services va poser des problèmes de performances... as-tu réalisé un benchmark te prouvant que des appels simultanés sur ces services créent un goulot d'étranglement ?

A+

[Callimard]

Bonsoir,

Merci beaucoup d'avoir répondu!

Alors du coup non malheureusement je n'ai pas fait des benckmarks mais c'est vrai que j'aurais dû. Cependant mon problème n'est pas vraiment de savoir si je dois exporter sur un ou plusieurs ports mes différents services. En fait je ne l'ai pas précisé mais je veux faire une système de session en RMI, et donc chaque client a un RemoteObject représentant une Session qui lui est associé. Le problème est qu'avec mes observations faites, chaque session = une thread et plus précisément un pool de thread. Du coup si j'ai beaucoup de clients, j'ai au moins un thread par client et cela risque fort de surcharger ma machine. Surtout que la plupart du temps il ne feront rien qu'attendre un appel de méthode.

Mais après plusieurs réflexion je pense que le RMI n'est pas vraiment la solution a mon problème et que je devrais plus me tourner vers Java EE ou CORBA qui (si j'ai bien compris) ont des systèmes pour gérer les sessions.

En tout cas s'il y a un moyen de créer des sessions en RMI facilement ou si il est possible de modifier le comportement des RemoteObject je suis preneur!

Merci encore d'avoir répondu

Bonne soirée.

Callimard

[Gugelhupf]

Bonjour,


En effet, je ne crois pas que RMI met à disposition un système de session pour identifier le client, son utilisation étant limité au LAN je ne crois pas que ce soit son but. J'ai moi-même rédigé un tutoriel CORBA et je n'ai jamais entendu ou expérimenté un système de session avec ce dernier. RMI et CORBA sont des protocoles RPC désuets, je te déconseille de les utiliser pour mettre une solution professionnelle en 2019.

Pour ce qui est de Java EE (= serveur HTTP), la solution qui consiste à utiliser l'identifiant de session HTTP peut convenir à ton besoin, il te suffira alors d'utiliser le JSESSIONID généré par le serveur.

Si tu souhaites rester dans les protocoles binaires telles que RMI ou CORBA, je te conseille de t'orienter vers gRPC (cf : "Google RPC") c'est une solution mis en avant par Google et elle est très performante d'après mes benchmarks, du moins pour la partie sérialisation et désérialisation avec Google Protocol Buffers. gRPC ne met pas à disposition un système de session natif, mais te propose une solution basé sur des tokens (ex : token JWT) que tu pourras faire passer en en-tête des requêtes contenant les messages exemple


A+