JBossDeveloper

It would also be cool if we could use the mbean-ref tags to perform roughly the same function as in an EJB. That is the loader on seeing an mbean-ref tag, creates a dynamic proxy object to the referenced MBean, and binds it to an MBean ENC. This would allow MBeans that actually work with other MBeans, quick and easy access to thier peers.

> 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...

Marc,
I'm *really* trying to understand what you mean here. Are you saying that you want to be able to use an ObjectName to in some way obtain the *same* reference that is used in Method.invoke()?

If so, are you also expecting to be able to directly cast that to a given type so you don't need to reflect or are you considering a Proxy()?

Otherwise could you dumb-down/flesh-out what need isn't being met by a "shy" implementation?

> 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).

This is silly, as long as JMX doesn't provide security, standardized remote lookup/invocation, standardized transaction semantics and a persistence engine, the similarity with EJB/JMX is a system one. The API is the JMX one. Exposing the *system* invocation API is an aberation compared to exposing the business API.

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


There are many ways to expose the JMX node to remote, we have 2 and another one standard invoker coming in.

> 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).

yes.

> Clean and straightforward.

...

Look, I am a fan of JMX as a system API building our app server, exposing singletons to users makes sense in some very controlled cases (where you need the capacity to find and invoke singletons), and is an aberation in many other cases. I am tired of the EJB this and that 0.02 criticism.

> public class JMXHelper {

purely local no distribution?

> 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
> d 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);
> }

so you wrote 2 lines to create the object name from the string and derive the parameters signature from the parameters...

cute

> /** 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;
> }
> }
>

get real.

I think many of the things you guys are talking about can be done today with mbean-ref and mbean-ref-list in mbeans configured throught a jboss-service.xml file.

Such mbeans should have a lifecycle with start and stop methods.

A named mbean-ref config element looks like:

<mbean-ref name="attname">(object name)</mbean-ref>

You need an Object-name valued attribute called "attname" on your mbean with a getter and setter.

Your mbean will not be started until all mbeans referred to in mbean-refs (and mbean-ref-lists) have been started. If one of them is stopped, all depending mbeans are stopped.

The ConnectionFactoryLoader and most of jbossmq works relying on this principle today.

mbean-ref-lists look like this:

<mbean-ref-list name="attname">
<mbean-ref-list-element>(object name)</mbean-ref-list-element>
<mbean-ref-list-element>(another object name)</mbean-ref-list-element>
</mbean-ref-list>

Here attname has to correspond to a collection valued attribute on your mbean.

I don't understand the function of marc's Registry, maybe he could explain. How is it different from doing mbean queries against the mbean server?

> I think many of the things you guys are talking about
> can be done today with mbean-ref and mbean-ref-list
> in mbeans configured throught a jboss-service.xml
> file.

Actually David, given that Marc has said

"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 think what is being asked for is something more like:

FooInstance X = MBeanProxy.for(ObjectName name, MBeanServer server, Class fooInstanceType);

Where the MBeanProxy factory only uses the MBeanServer to resolve the ObjectName to the POJO instance that the MBeanServer would be calling invoke() on anyways. Ok it wouldn't quite be a POJO, more like the invocationInterface (to preserve third party bindings).

That way each invoke() over the JMX bus doesn't incur a lookup cost because each method call would bypass the MBeanServer.

With cleverness you might even be able to use the MBeanProxies as objects to bind in jndi encs or whatever.

If that *is* what is being asked for, it's pretty trivial to code up.

Otherwise, I haven't just got the wrong end of the stick, I'm in a different forest.

Trev

> I think what is being asked for is something more
> like:
>
> FooInstance X = MBeanProxy.for(ObjectName name,
> MBeanServer server, Class fooInstanceType);
>
> That way each invoke() over the JMX bus doesn't incur
> a lookup cost because each method call would bypass
> the MBeanServer.

hmm ok.. this I can understand. So, we could just take the org.jboss.util.MBeanProxy and instead of doing server.invoke(), we'd store the MBeanEntry ref we store in the registry, and invoke() that instead...?

So with x invocations there is always just one lookup at proxy creation time.

And register the proxy as a registration/unregistration listener for keeping track of the validity of that reference..?

> And register the proxy as a
> registration/unregistration listener for keeping
> track of the validity of that reference..?

That's one way. I thought perhaps you'd just call a protected invalidate() method on the invocationInterface which nulled out the POJO ref it's holding.

Then you package up the NPException as a TargetIsGoneGoneGoneException and the MBeanProxy's invocationHandler could attempt a rebind X times or sleep and retry or whatever turns your crank. Eventually it get's another reference or dies in a blaze of glory.

Trev

true, true :)

hmm... that could potentially create a big performance gain in the invocation (is java.lang.reflect.Proxy fast?)

Wanna try it and get some initial numbers out of it? (I'm packing...)

Excellent idea! ;)

Ok, there are a lot of topics in this thread.

1. Dependency management. If one mbean uses another, how do they communicate that they are there, stopped, whatever? My suggestion about mbean-refs addresses this, I think

2. Direct non-jmx mediated communication. Now I think I see that this is what marc's registry is for, good. In combination with (1), you shouldn't need any exceptions: if the mbean you are using goes away, you will be stopped beforehand, so you won't be trying to use it. This works today for specific mbean object names: not for something like jini lookup where you might look for object names satisfying a certain pattern. An extension to this case might not be so hard.

3. How direct should direct object refs between mbeans be. If they are to a POJO they will be at least somewhat faster, however by using them you lose all the metaprogramming advantages of the interceptor stack, such as declarative transaction management, security, etc. Constructing a proxy to call that is a front for the interceptor stack can add back the metaprogramming, but it's not too clear to me yet what you gain over regular mbeanserver invocations. Don't you just lose a hashmap lookup of the ObjectName? Is this worth the extra complexity? Did I miss something?

> hmm... that could potentially create a big
> performance gain in the invocation (is
> java.lang.reflect.Proxy fast?)

Sounds like a beer-fund bet (something we do at work). I figure it'll be no faster unless you have a sh?t load of MBeans in the registry.

After all, while the MBeanProxy elminates the registry lookup it'll be mapping the reflection style method signature to the JMX style signature, which then is mapped back to reflection style by whatever is behind the invocationInterface.

> Wanna try it and get some initial numbers out of it?
> (I'm packing...)

Sure. I'd be surprised this isn't in the current codebase just as a convenience for calling invoke using the JMX RI. One of the first things I did with JMX was use Proxy to give me a *MBean that used the MBeanServer in the InvHandler.

Trev

> it'll be mapping the reflection style
> method signature to the JMX style signature

my bet is on this to kill the perf... ]:)

hmm.. though there's the Dan O'Connor proxy...

> Sure. I'd be surprised this isn't in the current
> codebase just as a convenience for calling invoke
> using the JMX RI.

It is. See org.jboss.util.MBeanProxy.

> Don't you just lose a hashmap lookup of the
> ObjectName? Is this worth the extra complexity? Did
> I miss something?


No David, you got it right.. proxy in front of the stack, avoid lookup per invocation.

Whether it's worth it... depends on the numbers... :)

> It is. See org.jboss.util.MBeanProxy.

Cough. Yes, you said that already. I really must learn to read :D

Happy Packing.
Trev

> Wanna try it and get some initial numbers out of it?

Shocking. Positively *SHOCKING*.

on a void method:

1M server invokes: 3950
1M proxy invokes: 15380

I've got another idea...

Trev