JMX scalabilty: peut-il être utilisé pour gérer plus de 400 instances?

Question

J'évalue des solutions pour gérer plus de 400 instances d'une application de type kiosque. Chaque instance exécute une application Java personnalisée qui affiche des informations et interagit avec les utilisateurs. Nous réfléchissons si nous devrions développer une solution personnalisée, essayer d'inclure le support de JMX ou trouver autre chose.

Les exigences sont simples:

1. Il doit être une solution source libre et ouverte;
2. Il doit être capable de gérer plus de 400 instances (par exemple: un gestionnaire gérant 400 clients compatibles JMX);
3. Il devrait être de préférence programmé en Java;
4. Nous avons besoin de métriques standards (par exemple: ressources disponibles, temps de fonctionnement, état actuel, etc.);
5. En option, nous aimerions envoyer des messages de contrôle aux instances.

Il semble que les fonctionnalités et la flexibilité de JMX soient ce que nous cherchions. Cependant, je n'ai pas trouvé beaucoup de choses sur l'évolutivité de JMX. Combien de "clients" un gestionnaire JMX peut-il gérer? Est-il possible de gérer 400 instances JMX simultanément? Existe-t-il une architecture ou une solution de contournement recommandée si elle ne gère pas directement autant de clients?

Merci pour toutes les indications

Answer 1

JMX est exactement ce que vous voulez.

En ce qui concerne le nombre de clients auxquels vous pouvez vous connecter, j'imagine que pour les parties de surveillance, vous auriez seulement besoin d'extraire les données des clients distants toutes les quelques secondes, au mieux, n'est-ce pas? Je ne suis pas sûr si une solution existe déjà qui vous permettra de surveiller les clients N et aussi les contrôler, donc vous voudrez probablement développer quelque chose vous-même - l'interaction avec les MBeans à distance avec le code JMX semble être triviale, ce qui transforme ensuite cela en un exercice de pouvoir écrire un programme qui peut communiquer simultanément avec 400 nœuds avec succès.