3 Replies Latest reply on Oct 24, 2007 11:42 AM by brian.stansberry

    No modification operations in CacheJmxWrapper?

    genman


      I would think a common management operation would be "clear" but I don't see this as part of the MBean operations in JBC2.0.

      Could clear() be added?

      Actually, I was thinking both clear() and removeNode(Fqn n) and removeNode(String s) would be nice as well.

        • 1. Re: No modification operations in CacheJmxWrapper?
          manik

          How does everyone else feel about this?

          My usual stance wrt. JMX is that it should *only* be for management information and statistics, not control, but we already do have some control elements in there (starting/stopping a cache) so this does make sense on one level. But at what point does this start becoming a full cache interface, with put() and get()?

          Also, the problem with removeNode() is that the Fqn object won't work on a JMX console, and the String version only makes sense if you use Fqns made of Strings - and adds confusion/noise to the API if you don't.

          • 2. Re: No modification operations in CacheJmxWrapper?
            manik

            ok, I just saw http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098262#4098262 which implicitly votes for a clear() API in JMX. :)

            • 3. Re: No modification operations in CacheJmxWrapper?
              brian.stansberry

              Seems to me if someone wants to expose more operations via JMX it's a trivial exercise to subclass CacheJmxWrapper(MBean) and do it.

              JBC should only support it directly if we agree that there's a good generally applicable use case for it that's compelling enough to trump the desire to not make CacheJmxWrapperMBean a control interface.

              Re: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098262#4098262, Hibernate exposes an API for evict data from the 2nd level cache. If there is no JMX interface to that API, that seems like something that should be dealt with by Hibernate. Encouraging users to bypass Hibernate and directly operate on JBC is analogous to someone exposing the JBC transaction table in JMX and letting users directly operate on it.

              Similar arguments apply to other AS usages of JBC. E.g. if I want to support a management layer that can remove a web session from the distributed web session cache, then that operation should be exposed by the web tier session manager. I don't want users directly going into the underlying cache and mucking around.

              Re: create/start/stop/destroy, you're right -- they don't fit. They are only there to support letting people deploy legacy -service.xml files in AS 5 by just changing the mbean's code attribute from org.jboss.cache.TreeCache to org.jboss.cache.jmx.CacheJmxWrapper. If we didn't want to support that (i.e. people have to use -beans.xml), we could remove the methods from the mbean interface. (Note I'm not advocating removing them at this late date; just discussing why they are there.)