1 Reply Latest reply: Nov 30, 2010 8:22 AM by jtahlborn RSS

    What JMX architecture and protocol should I be using?

    rupertlssmith
      Hi,

      I have an application that will run many instances on many different servers, and that can provide a set of JMX beans for external management. Changes to the configuration through the JMX interface will be written back to each app instances config files. Each application instance is capable of starting from its current config, and running without the external management UI being connected.

      There is a web app, that should be capable of finding all of the app instances, and through their JMX interfaces, provide the user with a list of currently running instances, and the ability to drill down and manage them, change configs, force restarts and so on.

      I'm new to JMX, and feeling a little confused by the number of available protocols and ways of connecting things up. Can someone suggest a simple way to get the above working?

      I know that RMI can sometimes be problematic with respect to firewalls, because it assigns service ports dynamically, and firewall admins would like a fixed port number to open. I found this example, which explains one way of getting around this problem:

      http://blogs.sun.com/mock/entry/remote_monitoring_hack_for_jmx

      Another possibility seems to be to use JMXMP.

      I don't think I really want the rmiregistry running on each server where an app instance resides. It seems to me that the 'registry', that is, the place where the JMX beans are looked up, should reside on the same machine where the JMX console webapp is running. Each app instance, when started will know the address of that machine, and attempt to register its MBeans with it (if it fails it can start anyway, and periodically retry exposing its management interface). Then the webapp just has one place to look to find all available apps.

      Possibly the registry can be embedded in the webapp too, so that a separate process does not need to be started?

      Thanks in advance for any advice, links, starting points you can give me.

      Rupert Smith

      Edited by: rupertlssmith on 30-Nov-2010 03:14
        • 1. Re: What JMX architecture and protocol should I be using?
          jtahlborn
          rupertlssmith wrote:
          I know that RMI can sometimes be problematic with respect to firewalls, because it assigns service ports dynamically, and firewall admins would like a fixed port number to open. I found this example, which explains one way of getting around this problem:

          http://blogs.sun.com/mock/entry/remote_monitoring_hack_for_jmx

          Another possibility seems to be to use JMXMP.

          I don't think I really want the rmiregistry running on each server where an app instance resides. It seems to me that the 'registry', that is, the place where the JMX beans are looked up, should reside on the same machine where the JMX console webapp is running. Each app instance, when started will know the address of that machine, and attempt to register its MBeans with it (if it fails it can start anyway, and periodically retry exposing its management interface). Then the webapp just has one place to look to find all available apps.
          i think you're on the right track with this. you definitely want a single registry running in a well known location. i'd run the registry on the webapp box, but in a separate process (this allows the webapp to be restarted without disrupting the registry). then, each remote box would register a connector in this registry, from which your webapp would locate the running instances. (note, you are not registering the mbeans with this registry, just an mbean connector for each remote mbean server).

          i'd avoid the jmxmp connector since it is not directly supported in the jdk and because there does not seem to be any compelling reason to use it over rmi (as long as you specify the rmi ports utilizing the technique in the post you referenced). if you did use the jmxmp connector, you'd still have a discovery problem, which the rmi connector solves with the rmiregistry.