1 2 3 Previous Next 32 Replies Latest reply on Dec 17, 2001 5:31 AM by Jiri

    Mbean to MBean communication or JMX on client

    Alexander Kogan Newbie

      Hello,

      We've been using JBoss for a while as a backbone of our
      customized application server. And we made quite a few
      our own MBean services for our problem domain.
      In order to get an access to those services we are usually bind a "live" nonserialized references into namespace by NonSerializableFactory.rebind. Not sure that it was the right way to do that, but anyway.

      Now are about to introduce a new type of client - full blown application. This application will use some of those services (and maybe some standard services
      as Naming, Timer and so on). So we are considering to use JMX on the client side as well.

      We'd like to implement many components/subsystems for this client application as MBeans as well. The idea is to be able to move components from server to client
      and back very easy to get different configurations.

      Does this sound absurd?

      The problem is that some components may use others (if those available), so the components are not completely decoupled. Again we may use NonSerializableFactory, but is there any other way? What could be the best way for communication between components (MBeans)?
      How can they discover each other?

      Actually, we'd like to get a full access to the most subsystem functionality (well, by reference?) but lose nothing in performance.

      Thanks in advance for any suggestions.

      Alexander.

      P.S. Is JBossMX going to be a JBoss proper JMX implementation instead of SUN RI?

        • 1. Re: Mbean to MBean communication or JMX on client
          marc fleury Master

          I was going to post separately talking about some of the points but will write in your thread instead :)

          > We've been using JBoss for a while as a backbone of
          > our
          > customized application server.

          yes this is going to be the future of JBoss, clearly.

          > In order to get an access to those services we are
          > usually bind a "live" nonserialized references into
          > namespace by NonSerializableFactory.rebind. Not sure
          > that it was the right way to do that, but anyway.

          Yes I asked juha about that the other day, there is no way in JMX to have the live reference as "isntance" is just metainformation. I think it has to do with JMX trying to encapsulate calls in indirection (which makes sense).

          However we clearly need this, and I have added (in RH only sorry) a org.jboss.system.Registry that is a dumb static map of classes you can keep there, typically the live reference to mbeans that I can lookup by ObjectName. This way I do away with JNDI bla bla bla and use the ObjectName directly. SImple, simple is good (although your approach is valid). I use the registry in teh new detached invokers to get live references to them from the proxy constructors.

          I was going to argue for that registry to move into the jmx codebase, as it is not distributed (!= JNDI) and is really a simple map.

          > Now are about to introduce a new type of client -
          > full blown application. This application will use
          > some of those services (and maybe some standard
          > services
          > as Naming, Timer and so on). So we are considering to
          > use JMX on the client side as well.
          >
          > We'd like to implement many components/subsystems for
          > this client application as MBeans as well. The idea
          > is to be able to move components from server to
          > client
          > and back very easy to get different configurations.
          >
          > Does this sound absurd?

          The question is not crystal clear so I won't make a judgment on the call.

          Moving components from one VM to the other is orthogonal to the JMX sphere imho, it is a pure deployer play, you can feed a JMX node deployer a service.xml script (or a full sar) that references the URL the classes come from so the client could install the classes this way. In fact it would be the preferred way to have distributed JMX nodes, client/server doesn't really apply here.

          > The problem is that some components may use others
          > (if those available), so the components are not
          > completely decoupled. Again we may use
          > NonSerializableFactory, but is there any other way?

          what are you talking about? is your client on the server or not? if they are separate VMs then the problem is one of distribution, if you are in one VM then ... the Registry or the JNDI approach work well.

          > What could be the best way for communication between
          > components (MBeans)?

          ? direct ref is good

          > How can they discover each other?

          You need the ObjectName at this point, this is not the "Jini discovery mechanism" the objectName in our case is passed through the MBean interfaces (i.e. it is configuration).

          > Actually, we'd like to get a full access to the most
          > subsystem functionality (well, by reference?) but
          > lose nothing in performance.

          what do you mean, the whole point of references is not losing the perf.

          > Thanks in advance for any suggestions.

          your questions were really not clear, take the time and format them with thought, please.


          > P.S. Is JBossMX going to be a JBoss proper JMX
          > implementation instead of SUN RI?

          yup


          • 2. Re: Mbean to MBean communication or JMX on client
            Juha Lindfors Master

            > Now are about to introduce a new type of client -
            > full blown application. This application will use
            > some of those services (and maybe some standard
            > services as Naming, Timer and so on). So we are
            > considering to use JMX on the client side as well.
            >
            > We'd like to implement many components/subsystems for
            > this client application as MBeans as well. The idea
            > is to be able to move components from server to
            > client and back very easy to get different
            > configurations.
            >
            > Does this sound absurd?

            not sure what you mean by the different configurations... something that configures an application component, or a configuration of components that define the application?

            The latter at least does not sound absurd.

            > The problem is that some components may use others
            > (if those available), so the components are not
            > completely decoupled. Again we may use
            > NonSerializableFactory, but is there any other way?
            > What could be the best way for communication between
            > components (MBeans)?
            >
            > How can they discover each other?

            Assuming you're not moving the dependent components (they stay in a different JVM) then a lookup service like JNDI is required. What should be bound then is the handle to the agent that can be used to configure a connector for remote communication.

            > Actually, we'd like to get a full access to the most
            > subsystem functionality (well, by reference?) but
            > lose nothing in performance.

            Reference of course means you're still working within the same JVM. As marc said in his post, it is a bit unclear what you want to do here. Are all the components in the same JVM or not?

            Due to the indirection provided by the MBean server, the invocation through it is never quite as fast as direct Java references. However, the MBean server invocations can be quite fast provided that certain guidelines are used with the implementation (avoid standard mbeans and default domain names, for instance).

            The map described by marc is in fact already inside the MBean server (but not exposed to the clients). Its maintenance is handled by the MBean server implementation (as new MBeans are added, removed, or updated). You can build a similar map inside your own application but then you will need to take care of the reference validity by other means.

            • 3. Re: Mbean to MBean communication or JMX on client
              marc fleury Master

              > The map described by marc is in fact already inside
              > the MBean server (but not exposed to the clients).
              > Its maintenance is handled by the MBean server
              > implementation (as new MBeans are added, removed, or
              > updated). You can build a similar map inside your own
              > application but then you will need to take care of
              > the reference validity by other means.

              of course you keep a map of references to object names, the question is would exposing the registry to users explicitely from JMX be a good idea.

              From what I see it is needed, I need, he needs it, returning the ObjectInstance is good but really doesn't help us, MAYBE we can return an implementation that exposes "Object getInstance()" so you keep the explicit lookup mechanisms for discovery but at least you can get a reference to the bean directly. I really think this would be important and I don't want to get in a rant as to why breaking indirection from JMX would be a secondary concern. Right now I do support this Registry in org.jboss.system.Registry and it feels like a sore thumb sticking out.

              Also, again, i really like the discovery of JMX, I think that the FLAT name=value pairs is superior to any hierarchical BULLSHIT like JNDI. I would want to keep that query but also include the native pointer.

              Then I can say in my proxy factory "lookup in server a connector that has "service=invoker,type=jrmp" (which I do today with an explicit ObjectName and I still get the reference to the object.

              The idea of the JMX Bus is a valid one, if you use the invoke() method (which we do in real live flow) so the live flow of methods will be through the dynamic mbean. but some small methods (getter setter, whatever) need not be coded in the invoke() flow, really cluters it, my spine shivers with thoughts of jdk1.0 like handleEvent gui programming that ended up with 1000 lines of if(event is bla bla) then... repeat...

              At this point I am more interested in an opinion, because frankly we should really expose that object and i will code it if you dont :D



              • 4. Re: Mbean to MBean communication or JMX on client
                Juha Lindfors Master

                > of course you keep a map of references to object
                > names, the question is would exposing the registry to
                > users explicitely from JMX be a good idea.

                yes, this was clear.


                > From what I see it is needed, I need, he needs it,
                > returning the ObjectInstance is good but really
                > doesn't help us, MAYBE we can return an
                > implementation that exposes "Object getInstance()" so
                > you keep the explicit lookup mechanisms for discovery
                > but at least you can get a reference to the bean
                > directly.

                The only argument so far seems to be speed, though. So I'm not convinced it is sorely needed yet. Without seeing other code which shows other reasons for doing this, I won't be able to get a clearer picture why this is such a big requirement. At the moment the invocation speed seems to be at a level where the configuration of interceptor stack will play a factor in simple benchmarks (ie. I'm running basic invocations 1 million times in less than a second on a laptop -- I can see the effect of adding an additional interceptor in the results. To me that's an indication the speed bottlenecks will probably be found somewhere other than the basic lookup and method invocation).


                > Also, again, i really like the discovery of JMX, I
                > think that the FLAT name=value pairs is superior to
                > any hierarchical BULLSHIT like JNDI. I would want to
                > keep that query but also include the native pointer.

                Native pointers would also bypass any interceptors in the server. This would make it more difficult to implement features like persistence or security in an MBean. Your view of MBean components in this case seems to be much lower level than mine.

                > At this point I am more interested in an opinion,
                > because frankly we should really expose that object
                > and i will code it if you dont :D

                Which is why JBossMX allows you to plugin your own implementation of mbean server.



                >
                >
                >

                • 5. Re: Mbean to MBean communication or JMX on client
                  Guy Rouillier Newbie

                  Marc said:
                  ========
                  > How can they discover each other?

                  You need the ObjectName at this point, this is not the "Jini discovery mechanism" the objectName in our case is passed through the MBean interfaces (i.e. it is configuration).
                  ========

                  My first and only MBean needs a db connection from an MBean, and the only way I could figure out how to get it was new InitialContext().lookup("java:/nemsDB"). Are you saying that I could have done this through some object name without a JNDI lookup? If so, how does that work?

                  Also, to enable EJBs to use my MBean, I included the set/getJNDIName as in the sample. This is a nuisance for all MBean writers to have to include. I'd like to see a class like ServiceMBeanSupportJNDI extending ServiceMBeanSupport that has these standard JNDI functions in it.

                  • 6. Re: Mbean to MBean communication or JMX on client
                    Alexander Kogan Newbie

                    Juha, Mark,

                    Firstly, thanks a lot for your answers.
                    Secondly, sorry for *unclear* questions.

                    > > names, the question is would exposing the registry to
                    > > users explicitely from JMX be a good idea.
                    >
                    > yes, this was clear.

                    It will be good from "outside developers" side.
                    But it maybe wrong from "conceptual, JMX spec" side.

                    However, we are not asking to expose the MBean
                    reference to management applications (and it's not possible for remote apps anyway),
                    but rather for other MBeans (in the same VM) and for functionality built
                    on top of JMX-server.

                    Simple use case:

                    I'm mostly using MBeans to wrap external services, native libraries or
                    multi-treaded libraries and use them inside of EJBs,
                    Servlets or other MBeans (relations?)

                    I don't want to expose all "business" MBean methods
                    for external management applications and thus I didn't
                    include them into MBean interface. Moreover, sometimes,
                    I can't even do that, because arguments are complex nonserializable
                    objects.

                    What I want is to get a reference to MBean and use "non-managed"
                    methods.

                    Second use case:

                    We also have "full-blown" client application, which also build on
                    top of JMX technology (also using SUN RI) and this application reuses
                    some of MBeans from the server. Mbean to Mbean and application to MBean
                    communication are much complex here and I also need an access by reference.


                    Does this mean that I'm abusing JMX?

                    Thanks again,

                    Alex

                    • 7. Re: Mbean to MBean communication or JMX on client
                      marc fleury Master


                      > You need the ObjectName at this point, this is not
                      > the "Jini discovery mechanism" the objectName in our
                      > case is passed through the MBean interfaces (i.e. it
                      > is configuration).
                      > ========
                      >
                      > My first and only MBean needs a db connection from an
                      > MBean, and the only way I could figure out how to get
                      > it was new InitialContext().lookup("java:/nemsDB").
                      > Are you saying that I could have done this through
                      > some object name without a JNDI lookup? If so, how
                      > does that work?

                      yes that is what I doing in rh 3.0 I use the *objectname* as the key to lookup, this is in a layer above JMX, I am asking for that to be in our JMX, trivial point, wether it is or not I have to use it.

                      Here you are talking about 2 names the JNDI and JMX names, I just use one.

                      > Also, to enable EJBs to use my MBean, I included the
                      > set/getJNDIName as in the sample. This is a nuisance
                      > for all MBean writers to have to include. I'd like
                      > to see a class like ServiceMBeanSupportJNDI extending
                      > ServiceMBeanSupport that has these standard JNDI
                      > functions in it.

                      I am not for the "multiplication" of names and APIs to do so. You have preRegister that passes the OBjectName try to use that naming scheme.


                      my point about having to pass it is that the one that looks up needs to know the ObjectName and/or the jndi name, I pass that in a standard mbean call so I can configure it from jboss-service.xml

                      marcf

                      • 8. Re: Mbean to MBean communication or JMX on client
                        marc fleury Master

                        > Simple use case:
                        >
                        > I'm mostly using MBeans to wrap external services,
                        > native libraries or
                        > multi-treaded libraries and use them inside of EJBs,
                        > Servlets or other MBeans (relations?)
                        >
                        > I don't want to expose all "business" MBean methods
                        > for external management applications and thus I
                        > didn't
                        > include them into MBean interface. Moreover,
                        > sometimes,
                        > I can't even do that, because arguments are complex
                        > nonserializable
                        > objects.

                        Does the spec require serializable in the api??? or are you talking about why JNDI is not really an option here.


                        In any case, exposing the api to native interfaces without the MBean api is a trivial point and this discussion is getting in the way of productive work.

                        > What I want is to get a reference to MBean and use
                        > "non-managed"
                        > methods.

                        clearly

                        > Second use case:
                        >
                        > We also have "full-blown" client application, which
                        > also build on
                        > top of JMX technology (also using SUN RI) and this
                        > application reuses
                        > some of MBeans from the server. Mbean to Mbean and
                        > application to MBean
                        > communication are much complex here and I also need
                        > an access by reference.
                        >
                        >
                        > Does this mean that I'm abusing JMX?

                        Strictly speaking yes, but who cares.

                        It is for me the natural JMX usage. We show it everyday in JBoss. The problem with JMX is that it is a very "shy" spec, it sees the JMX bus as a way to just add "management" of components and how to bring them up and talking to them should only be management operations. Even juha is falling prey to this shy view. in Jboss and the client application you build is a clear example of JMX as a system view under the application. The question is to merge the naming and querying to expose the singleton objects in the VM as JMX managed objects but full fledged "stripped" objects in the VM. Direct references. If the kid doesn't see that, then I am not going to care any more and just bypass him...

                        marcf

                        • 9. Re: Mbean to MBean communication or JMX on client
                          Vad Newbie

                          Just to add my little experience:

                          I have an application composed of connectors (to legacy CORBA servers), and a MDB which has to decide to which connector it should forward messages it receives, based on a "routing table" which is manageable via a MBean. As my MDB has to route hundreds of messages per seconds,I want it to have a direct access to my routing hashtable (not going through dynamic invocation), so I've added a method which returns a ref to the real object Mbean:
                          MyMBean getService();

                          I feel abusing JMX, because if my MBean were to be stopped, my reference would be stale...

                          But what should I do when perf *really* matters?

                          Vad

                          • 10. Re: Mbean to MBean communication or JMX on client
                            marc fleury Master

                            > through dynamic invocation), so I've added a method
                            > which returns a ref to the real object Mbean:
                            > MyMBean getService();
                            >
                            > I feel abusing JMX, because if my MBean were to be
                            > stopped, my reference would be stale...

                            that is the only thing that is really a problem.

                            Notifications would be needed here.

                            > But what should I do when perf *really* matters?

                            There is performance which is big but the dynamic one is good enough , that is part of the point juha is making. 100 calls per seconds is *nothing* even for a dynamic mbean.

                            The other point on top of speed is "coding" I don't want to maintain a thousand extra calls on the API, specifically a "getService" that I need to call on all the MBeans.

                            Your usage of MBean.getService assumes that you already have a reference to the MBean, we go a bit further by mappping the ObjectName to the reference.

                            There is nothing JMX can do about people using live references to objects, that is just the nature of the beast, if you want to prevent against failure you need to code proper notification management.

                            marcf

                            • 11. Re: Mbean to MBean communication or JMX on client
                              Adrian Brock Master

                              Hi,

                              Staleness can be checked in JBoss services.

                              if (myService.getState() != ServiceMBean.STARTED)
                              // get the new service

                              Somebody mentioned something about getState() being added to the JMX specification. Can't remember where.

                              Regards,
                              Adrian

                              • 12. Re: Mbean to MBean communication or JMX on client
                                marc fleury Master


                                > Staleness can be checked in JBoss services.
                                >
                                > if (myService.getState() != ServiceMBean.STARTED)
                                > // get the new service

                                that is one...

                                but it won't be foolproof, you should in fact synchronize access to the underlying reference in *removal* access. BTW Juha in the book investigation did you find out if the lifecycle operations were *synchronized* with the normal operations. We know that management operations are not synchronized but are management to lifecycle synchronized (otherwise the above point is moot). do you know ?:|

                                > Somebody mentioned something about getState() being
                                > added to the JMX specification. Can't remember
                                > where.

                                JSR77 the spec I and adreas are on.

                                getState is already in JBoss.

                                marcf
                                > Regards,

                                • 13. Re: Mbean to MBean communication or JMX on client
                                  Alexander Kogan Newbie

                                  Mark,

                                  Where is org.jboss.Registry (you've mentioned).
                                  I tried to find it in this morning CVS snapshot,
                                  but nothing was there.
                                  Found only BasicMBeanRegistry in org.jboss.mx.server

                                  Was that removed or I misunderstood you?

                                  Thanks,
                                  Alex.

                                  • 14. Re: Mbean to MBean communication or JMX on client
                                    Jiri Newbie

                                    just to add something from our experience...

                                    We see JMX MBeans as a *lightweight* equivalent to EJBs with very similar features as a container, indirection, query/lookup service. All those things are implemented in standard JMX.
                                    The weak point of the current JMX architecture is a transparent remote access to MBeans (AFAIK next JMX spec is trying to solve that).

                                    To invoke a MBean from other components(Mbean, EJB) we have implemented the following small helper class:

                                    public class JMXHelper {
                                    public static final String DOMAIN_NAME = "Foo";
                                    private static MBeanServer mBeanServer = null;

                                    /** Invokes a method on a MBean. Signatures of arguments are dynamically reflected.
                                    * If any of the arguments is a subclass of expected type, use the invoke with explicit signatures
                                    */
                                    public static Object invoke(String objectName, String actionName, Object[] params) throws Exception {
                                    String[] signatures = new String[params.length];
                                    for (int i = 0; i < params.length; i++) signatures = params.getClass().getName();
                                    return invoke(objectName, actionName, params, signatures);
                                    }

                                    /** Invokes a method on a MBean.
                                    */
                                    public static Object invoke(String objectName, String actionName, Object[] params, String[] signatures) throws Exception {
                                    // invoke method on MBeanServer
                                    try {
                                    return getMBeanServer().invoke(
                                    new ObjectName(DOMAIN_NAME + ":service=" + objectName),
                                    actionName,
                                    params,
                                    signatures);
                                    } catch (RuntimeMBeanException e) {
                                    Exception ex = e.getTargetException();
                                    throw ex;
                                    } catch (... e) {
                                    ...
                                    }
                                    }

                                    private static MBeanServer getMBeanServer() throws JMXException {
                                    if (mBeanServer == null) {
                                    // Get instance to MBeanServer
                                    Collection col = MBeanServerFactory.findMBeanServer(null);
                                    if (col.isEmpty()) {
                                    throw new JMXException("No MBeanServer found");
                                    }
                                    // Assumes there is only one :-)
                                    mBeanServer = (MBeanServer)col.iterator().next();
                                    }
                                    return mBeanServer;
                                    }
                                    }

                                    The 'objectName' argument is the same kind of *string* identification as the JNDI name is, so I don't understand why to bind it to JNDI as well (unless you need to access the name remotely).

                                    We basically do not do any difference between *manageable* and *other business* methods, we put all public methods to MBean interface.
                                    If we need a better performance, we use dynamic MBeans. The time spent on JMX invocation is minimal comparing to the time spent inside the methods (business logic, DB access).

                                    Clean and straightforward.


                                    Jiri.

                                    1 2 3 Previous Next