7 Replies Latest reply on Sep 13, 2006 6:18 AM by Manik Surtani

    JBossCache 2.0.0 and JMX: Design ideas

    Manik Surtani Master

      Hi, all.

      Thinking about the JMX interface to expose in JBoss Cache 2.0.0 at the moment. I'm not keen on exposing the entire cache interface as we did in the 1.x series, as I feel this is too cumbersome. What I hope to do is to expose a few classes of methods:

      1) Lifecycle methods - create, start, stop, destroy
      2) Configuration (read-only) getter - which retrieves a String (or formatted HTML for web based JMX consoles) representation of the configuration
      3) setters for a specific subset of config elements which may be changed at runtime
      4) Cache information methods (numNodes, numAttributes, lockInfo, printDetails) which print as Strings or as formatted HTML (for web based JMX consoles)

      Is there an actual need for operational cache methods, like put(), get(), etc. via JMX? What about addListener()?

      Just trying to understand how people use the cache with JMX at the moment.

      Cheers,
      Manik

        • 1. Re: JBossCache 2.0.0 and JMX: Design ideas
          Ben Wang Master

          Re: 2, print it as a String is fine for small space of parameters but it will be difficult to read if we dump of all it as one. Is it possible to push the config info to the individual interceptor mbean?

          Finally, I do thing we need to support the operational method like put and get. If we say we expose the Cache as JMX MBean, then people would expect to operate on the mbean as well, IMO.

          • 2. Re: JBossCache 2.0.0 and JMX: Design ideas
            Manik Surtani Master

            Well, doing a printDetails() can be even longer. :-)

            Pushing the config elements to various interceptor MBeans is a holy grail of sorts, but is not feasible for all elements (some aren't attached to any interceptor, others are used by >1 interceptor, etc).

            Re: operations on the cache via the MBean, I'd have to ask why. At the end of the day the JMX interface is a management interface, not an operational registry like JNDI. But at the end of the day, if people need work with the cache via JMX then so be it.

            What about a getter on the JMX interface that returns a Cache object which can then be used? This would only work programmatically and within the same VM, of course, and not via a management console.

            • 3. Re: JBossCache 2.0.0 and JMX: Design ideas
              Ben Wang Master

              1. You are right on printDetails(). So I guess if config element output is formatted for human reading, a string output is fine as well.

              2. If we will have mbean on the interceptor level, then I'd suggest to push as much config attributes as possible since you are passing the config object in the chain anyway. This way, we reduce the cluttering of the parameters from the main Cache MBean.

              3. Well, JMX specifically lists operation methods to provide decoupling of different services, doesn't it? But on the other hand, once user uses cache.getRoot().getChild(fqn) to obtain a Node, then there goes the decoupling. :-) So yes, go ahead and just provide a getCache operation then.

              • 4. Re: JBossCache 2.0.0 and JMX: Design ideas
                Manik Surtani Master

                re: 3) I'd still like to figure out how and why people use JMX to get a hold of a cache instance.

                I mean, maybe we should provide a JNDI binding for this sort of thing and only provide a trimmed down JMX interface for statistics, configuration, lifecycle. Basically, management, not operation.

                • 5. Re: JBossCache 2.0.0 and JMX: Design ideas
                  Manik Surtani Master

                  Any more thoughts on this? Are we happy to provide:

                  1) A ServiceName attribute which binds a CacheMBean interface which allows retrieval of configuration and statistics, as well as lifecycle operations, and setters on some configs that may be changed at runtime

                  and

                  2) A JndiName attribute which bnds a Cache instance to JNDI for *operational* use?

                  Both attribs would be optional ...

                  • 6. Re: JBossCache 2.0.0 and JMX: Design ideas
                    Brian Stansberry Master

                    I think that would be OK for usage in the AS, but... does JBC have the ability to bind a Cache instance in JNDI? AFAIK when we do that now we're relying on the AS's proxy factories.

                    For the standard caches in the AS we could always add beans to the config files to do this, but that doesn't work outside the AS.


                    The usage I have for accessing the cache via JMX is in AS unit tests, for which JNDI would be fine. The other one I can think of would be more app-specific mgmt consoles, e.g. show me the names all the sessions in the cache for webapp X, which would use a JMX call to getChildrenNames. For a mgmt console people don't want to use JNDI as it leads to the need to have JBC classes available to the console.

                    • 7. Re: JBossCache 2.0.0 and JMX: Design ideas
                      Manik Surtani Master

                       

                      "bstansberry@jboss.com" wrote:
                      I think that would be OK for usage in the AS, but... does JBC have the ability to bind a Cache instance in JNDI? AFAIK when we do that now we're relying on the AS's proxy factories.


                      Is this necessary? Wouldn't a simple

                      new InitialContext().bind(jndiName, cacheInstance);
                      


                      do the trick, since we'd only be binding to local JNDI?


                      "bstansberry@jboss.com" wrote:
                      The other one I can think of would be more app-specific mgmt consoles, e.g. show me the names all the sessions in the cache for webapp X, which would use a JMX call to getChildrenNames. For a mgmt console people don't want to use JNDI as it leads to the need to have JBC classes available to the console.


                      I agree, but could this be construed as management info - and be made avbl in the CacheMBean? E.g., a method like:

                       /**
                       * Returns a string representation of all children and the number of
                       * attributes in each child, as well as number of children on each child.
                       * NB: Only works for String based Fqns.
                       */
                       String getChildrenNames(String fqn);