JMX scalabilty: can it be used to manage 400+ instances?

I'm evaluating solutions for managing 400+ instances of a kiosk-like application. Each instance runs a custom Java application开发者_运维百科 that displays information and interacts with users. We are pondering if we should develop a custom solution, try to include JMX support for it or find something else.

The requirements are simple:

1. It must be a free and open source solution;
2. It must be able to manage more than 400 instances (for example: one manager managing 400 JMX-enabled clients);
3. It should be preferably programmed in Java;
4. We need standard metrics (for example: available resources, running times, current status, etc);
5. Optionally we would like to send some control messages to the instances.

It seems that JMX features and flexibility is what we were looking for. However, I haven't found much about JMX scalability. How many "clients" can one JMX manager handle? Is it possible to manage 400 JMX instances concurrently? Is there any recommended architecture or workaround if it doesn't handle so many clients directly?

Thanks for any hints

JMX is exactly what you want.

As far as how many clients you can connect to, I'd imagine that for the monitoring portions of it, you'd only really need to fetch data from the remote clients every few seconds, at the most, right?

I'm not sure if a solution already exists which will allow you to monitor N clients and also control them, so you'd likely want to develop something yourself - interacting with remote MBeans with JMX code seems to be trivial, which then turns this into an exercise of being able to write a program which can concurrently communicate with 400 nodes successfully.