1 2 Previous Next 15 Replies Latest reply on Jan 9, 2003 3:23 AM by sanne

    How is the cache tied to JMX?

      In Jboss JMX is not only used as a management framework, but also as an invocation layer.

      Is the cache going to be invocable for users via JMX, or is the MBean nearly going to be a wrapper that registers the embedded cache object with JNDI for users.
      Or is a proxy going to be registered to JNDI that patches the invocations to the JMX invocation layer?

        • 1. Re: How is the cache tied to JMX?
          belaban


          > For no 1.:
          >
          > My basic design idea was to make a Model Mbean:
          >
          > public class CacheService implements ModelMbean,
          > MBeanRegistration, XMBeanConstants {
          >
          > }
          >
          > This does not use any ICache/CacheImpl
          > interfacing/Extending.
          >
          > Then in the MLet code pass an argument to the
          > constructor which type of class the managed resource
          > should be. In this case the Managed resource is a
          > subclass of the Cache interface.

          Actually a class *implementing* Cache. But it could be any POJO. This is in line with what Bill and Dain want to do with CMP 2.0. In our case it should have a static and a dynamic part: the static part is a regular MBean for the Cache interface, and the dynamic part is a dynamic MBean for everything on top of Cache, that is, Cache-implementation specific attributes (maybe even methods).


          > Which operations to
          > support can now dynamicaly be determined by
          > reflecting the managed resource class type. And
          > during the construction fase the ModelMBean can
          > register a proxy in JNDI.

          Do we need this ? I guess we can query an MBean through an MBean server directly, right ?


          > But now we endup with a
          > Model MBean, not a DynamicMBean.

          Fine if this works. But what I want to avoid is to have to declare attrs/methods to be 'managed' though the ModelMBean in an XML file. Or if omitted, manage all attrs/methods, and make the XML file optional. (I don'tknow much about ModelMBeans).



          > Where I go amiss is:
          >
          > <mbean code="org.jboss.cache.CacheImpl"
          &gt; name="jboss:service=CacheService">
          >
          > org.jboss.cache.CacheImpl has got to be a MBean
          > somehow either by implementing a DynamicMBean
          > interface, either by being a ModelMBean.

          Right. Your ModelMBean adaptor would add an MBean interface to the CacheImpl class.


          Bela

          • 2. Re: How is the cache tied to JMX?
            belaban


            > Is the cache going to be invocable for users via JMX,
            > or is the MBean nearly going to be a wrapper that
            > registers the embedded cache object with JNDI for
            > users.

            It will definitely be invokable via JMX. As a matter of fact, if you download the latest from the CVS, generate jboss-cache.jar and put both jboss-cache.jar and cache-service.xml into the ../server/all/deploy directory, then you can already use jmx-console. Note that only attributes are implemented thus far, no methods yet. I'll probably use TransactionalHashtable from JavaGroups as a delegee for the methods. Let's see...

            So, yes, access is possible via JMX. But, if you use the cache internally, I'm also thinking of providing a DynamicProxy which implements Cache, so that you have both a strongly typed interface for users of the service and acces to the JMX side.


            > Or is a proxy going to be registered to JNDI that
            > patches the invocations to the JMX invocation layer?

            Yes, that's what I have in mind. Interested ?



            Bela

            • 3. Re: How is the cache tied to JMX?

              Taker?

              Let me see... If we have the Model Mbean then we should use:

              public void postRegister(Boolean registrationDone)

              where registrationDone indicates if the Mbean registerd succesfully (that's good!).

              In post Register we should do something like (from JBoss Javadoc):

              A utility class that allows one to bind a non-serializable object into a local JNDI context.
              The binding will only be valid for the lifetime of the VM in which the JNDI InitialContext lives.
              An example usage code snippet is:
              // The non-Serializable object to bind
              Object nonserializable = ...;
              // An arbitrary key to use in the StringRefAddr. The best key is the jndi
              // name that the object will be bound under.
              String key = ...;
              // This places nonserializable into the NonSerializableFactory hashmap under key NonSerializableFactory.rebind(key, nonserializable);
              Context ctx = new InitialContext();
              // Bind a reference to nonserializable using NonSerializableFactory as the ObjectFactory
              String className = nonserializable.getClass().getName();
              String factory = NonSerializableFactory.class.getName();
              StringRefAddr addr = new StringRefAddr("nns", key);
              Reference memoryRef = new Reference(className, addr, factory, null);
              ctx.rebind(key, memoryRef);

              Question is whether nonserializable is necessary,
              but it also appears in the JBoss Docu online, so it's a starting point.

              Then the proxy should be designed. It should:

              a. have a reference to the server
              b. patch all invocations through to the server using the reference.

              Point a. can be taken care of in the postRegister method I imagine, otherwise the server reference should be instaniated during lookup.

              Then we are left with the patching logic.

              The signatures of the dynamic proxy look like:

              public Object invoke(Object proxy,
              Method m, Object[] args) throws Throwable


              which looks like the MBean invocation signature:

              m_server.invoke(m_name, "store", new Object[] {data}, new String[] {"java.lang.Object"});

              or

              m_server.setAttribute(m_name,"my property")

              Hopefully we can get away with the get and set attributes,
              otherwise we'll end up with a signature circus I'm afraid, in case we want one proxy for all the different CacheImpl MBeans, but that can be sorted out later.

              The one thing to decide then is whether a CacheProxyFactory or a CacheProxy should be registered with JNDI. This hinges on whether the m_server reference is thread-safe. I think it is (?)

              This should be the general outline.

              Please observe the lacunes in my 5-min implementation ;-)

              But then we should first have a Model Mbean to register itself.

              • 4. Re: How is the cache tied to JMX?

                I'll give a shot at the Model Mbean, but it'll take a couple of days since I'm kind of busy. If that's no problem.

                • 5. Re: How is the cache tied to JMX?

                  O.k. DynamicMbean/Model Mbean circus.

                  ModelMBean = DynamicMbean+PersistentMBean+ModelMBeanNotificationBroadcaster (Juha Lindors JMX p.106)

                  So basically the difference between Dynamic/Model MBean shouldn't be that big. But...

                  (Juha Lindors JMX p.233) states that where Model MBeans can be configured by XML they can also be instiated by JDBC, any datasource, and yes: introspection.

                  Actually this whole chapter 8 is about how to do this. It has a listing of a MetaDataBuilder interface, and a XMLMetaDataBuilder, so it's up to us to implement a IntrospectionMetaDataBuilder.

                  Maybe a Dynamic Mbean could suffice, but this looks like a good starting point not?

                  • 6. Re: How is the cache tied to JMX?

                    O.k. a server reference can be obtained using the MBeanRegistration interface, of which the postRegister is part of too.

                    Once we have the reference, we can put it in the proxy object. But then we definitely want to use the NonSerializable factory, with serialization we would loose the reference I think.

                    • 7. Re: How is the cache tied to JMX?

                      O.k. I'm happily talking to myself now.
                      But ut helps. From the jboss website (about the jmx book):

                      Additional features included in the JBossMX 1.0 release:

                      XMBean Model MBean implementation. Supports externalizing the MBean management interface to an XML file, or generating it based on Standard MBean naming conventions.

                      XMBean Model MBean is wat we want.

                      • 8. Re: How is the cache tied to JMX?
                        belaban

                        Note that we are talking about 2 tasks:

                        1. Implementation of CacheImplMBean as DynamicBean and
                        2. DynamicProxy for CacheImpl MBean

                        For #1 the requirements are that I can say the following:



                        Now, CacheImpl does *not* implement CacheImplMBean at all. Instead it says (e.g. in the constructor):

                        CacheImpl impl;
                        CacheImplMBean mb=new CacheImplMBean(...);
                        mb.provideFacadeFor(impl);

                        The CacheImplMBean extends the Cache interface.
                        The last statement tells the CacheImplMBean to use reflection to provide setters and getters for CacheImpl.

                        The great advantage here is that we do *not* have to hard-code all CacheImpl-specific getters and setters in CacheImplMBean. This way, CacheImplMBean can provide a dynamic MBean facade for *any* cache implementation !
                        If people want to plug in different implementations of Cache, they can use CacheImplMBean too.

                        For #2 the requirements are that other code in the JBoss server may not want to always have to say:
                        Class[] type={...};
                        Object[] args={..};
                        target.invoke("put", types, args);

                        for each call on the Cache. They may want to say for convenience:
                        cache.put("a", new Integer(3));

                        Therefore it would be nice to have a dynamic proxy which provide a Cache interface to the caller, and uses JMX invocations as the backend, e.g.:

                        ProxyFactory fact;
                        String mbean_service="jboss:service=CacheService";
                        Cache c=(Cache)fact.getProxyForMBean(mbean_service);
                        c.put(...);
                        c.get(...);

                        I hope this clears up the confusion !
                        Bela

                        • 9. Re: How is the cache tied to JMX?

                          Ok., no confusion here about 1. and 2., but figured out the confusion.

                          For no 1.:

                          My basic design idea was to make a Model Mbean:

                          public class CacheService implements ModelMbean, MBeanRegistration, XMBeanConstants {

                          }

                          This does not use any ICache/CacheImpl interfacing/Extending.

                          Then in the MLet code pass an argument to the constructor which type of class the managed resource should be. In this case the Managed resource is a subclass of the Cache interface. Which operations to support can now dynamicaly be determined by reflecting the managed resource class type. And during the construction fase the ModelMBean can register a proxy in JNDI. But now we endup with a Model MBean, not a DynamicMBean. This ends up working exactly the other way around as you describe it ;-)!

                          Alternatively if CacheImpl is going to be managed as a DynamicMBean, then either the CacheImpl, or one of its superclasses (possibly interface ICache, no clue if that is compliant) has to implement the DynamicMBean interface.

                          Where I go amiss is:



                          org.jboss.cache.CacheImpl has got to be a MBean somehow either by implementing a DynamicMBean interface, either by being a ModelMBean.

                          For no 2.: This is where I managed to confuse you and myself. What I actually thought of doing was during task 1. register a dynamic proxy with JNDI, presetting it with a server reference so that when the proxy operates on the mbean, it doesn't have to lookup a server every time. But this is sort of sticky/dirty, and probably plainly wrong.

                          For the record: these are my first steps into JMX. I hope to contribute to the advancement of JCache, instead of stalling it.

                          • 10. Re: How is the cache tied to JMX?


                            >
                            > > For no 1.:
                            > >
                            > > My basic design idea was to make a Model Mbean:
                            > >
                            > > public class CacheService implements ModelMbean,
                            > > MBeanRegistration, XMBeanConstants {
                            > >
                            > > }
                            > >
                            > > This does not use any ICache/CacheImpl
                            > > interfacing/Extending.
                            > >
                            > > Then in the MLet code pass an argument to the
                            > > constructor which type of class the managed
                            > resource
                            > > should be. In this case the Managed resource is a
                            > > subclass of the Cache interface.
                            >
                            > Actually a class *implementing* Cache.

                            Ofcourse ....

                            >But it could
                            > be any POJO.

                            Think so.

                            >This is in line with what Bill and Dain
                            > want to do with CMP 2.0. In our case it should have a
                            > static and a dynamic part: the static part is a
                            > regular MBean for the Cache interface,

                            I think I know what you mean, but when the implementing class is reflected by the Model MBean, it checks if the class implements ICache, making sure that a minimum of methods is always available.

                            > and the
                            > dynamic part is a dynamic MBean for everything on top
                            > of Cache, that is, Cache-implementation specific
                            > attributes (maybe even methods).
                            >
                            >
                            > > Which operations to
                            > > support can now dynamicaly be determined by
                            > > reflecting the managed resource class type. And
                            > > during the construction fase the ModelMBean can
                            > > register a proxy in JNDI.
                            >
                            > Do we need this ? I guess we can query an MBean
                            > through an MBean server directly, right ?

                            Yes. But is possible I think to create a dynamic proxy based on the ICache interface which can be registered, so that applications can use that one instead of invoking the MBean intself directly.


                            >
                            >
                            > > But now we endup with a
                            > > Model MBean, not a DynamicMBean.
                            >
                            > Fine if this works. But what I want to avoid is to
                            > have to declare attrs/methods to be 'managed' though
                            > the ModelMBean in an XML file.

                            The plan is to replace the XML file with a reflection routine: basically they are both datasources

                            >Or if omitted, manage
                            > all attrs/methods, and make the XML file optional. (I
                            > don'tknow much about ModelMBeans).
                            >
                            >
                            >
                            > > Where I go amiss is:
                            > >
                            > > > name="jboss:service=CacheService">
                            > >
                            > > org.jboss.cache.CacheImpl has got to be a MBean
                            > > somehow either by implementing a DynamicMBean
                            > > interface, either by being a ModelMBean.
                            >
                            > Right. Your ModelMBean adaptor would add an MBean
                            > interface to the CacheImpl class.
                            >

                            More or less. Actually what you is register a ModelBean (a very generic type) and shout: eh... by the way ... manage this. That is where the CacheImpl comes in.

                            If I'm right, also refering to your earlier remark about POJO, you could basically put in any class, and it will be managed. But I'll make damn sure that class managed by the Cache Model MBean implements ICache.


                            >
                            > Bela

                            JMX isn't that bad, but there seem to be different starting points: better make sure it is the right approach.Come to think if it, all this is kind of JBoss 3-ish ;-(((

                            Shall I run this plan through the JMX forum, and get some feedback?

                            Thanks for replying.

                            Sanne

                            • 11. Re: How is the cache tied to JMX?
                              belaban


                              > I think I know what you mean, but when the
                              > implementing class is reflected by the Model MBean,
                              > it checks if the class implements ICache, making sure
                              > that a minimum of methods is always available.

                              Yes. But don't you think such a beast would be interesting for other folks as well ? I mean, why do we have to implement some stupid MBean interface anyways ? I'd much rather just say, here's my implementation, it has some public methods and some getters/setters, now manage it.

                              ModelMBean comes close to doing this job, but it still requires an XML file for definition of methods/attrs to be managed (if I'm correct). Maybe you want to run this by the JMX folks...






                              > The plan is to replace the XML file with a reflection
                              > routine: basically they are both datasources

                              Okay.



                              > If I'm right, also refering to your earlier remark
                              > about POJO, you could basically put in any class, and
                              > it will be managed. But I'll make damn sure that
                              > class managed by the Cache Model MBean implements
                              > ICache.

                              Yes. POJOs is where we're going.



                              > JMX isn't that bad, but there seem to be different
                              > starting points: better make sure it is the right
                              > approach.Come to think if it, all this is kind of
                              > JBoss 3-ish ;-(((

                              Yes (or 4). POJO support are definitely 4.



                              > Shall I run this plan through the JMX forum, and get
                              > some feedback?

                              Yes, why not.

                              Bela

                              • 12. Re: How is the cache tied to JMX?

                                > ModelMBean comes close to doing this job, but it still
                                > requires an XML file for definition of methods/attrs to be
                                > managed (if I'm correct).

                                No it doesn't. You're free to use whatever means suits you to build up the meta data exposed by a model mbean.

                                • 13. Re: How is the cache tied to JMX?
                                  belaban


                                  > No it doesn't. You're free to use whatever means
                                  > suits you to build up the meta data exposed by a
                                  > model mbean.

                                  Even better. So we don't need to reinvent the wheel.
                                  Cheers,
                                  Bela

                                  • 14. Re: How is the cache tied to JMX?

                                    O.k. I'll take that as a yes.

                                    In the JMX forum there is also a discussion about Plain Old Java Objects and XMBeans.

                                    Right I'm kind of busy, but I've got some days scheduled next week to work on this. I'll report more on the XMBeans, and maybe go for an implementation.

                                    1 2 Previous Next