Bug 566256

None of these attributes is serializable and therefore the value is not available remotely.

This makes it impossible to access these values from an RHQ plugin.

In another words, this would require changes in the JBoss AS.

(In reply to comment #1)
> None of these attributes is serializable and therefore the value is not
> available remotely.
> 
> This makes it impossible to access these values from an RHQ plugin.
> 
> In another words, this would require changes in the JBoss AS.

Not sure what you are saying here. I must be missing something. For EJB3, the return type is org.jboss.ejb3.statistics.InvocationStatistics, which is Serializable and appears to deliver its attribute as a Map. I have not looked into EJB2 but I would suggest that we at least support the metrics of EJB3 if they are there.

In the past I believe I bumped into a problem where an attribute that showed as "Unavailable" in jconsole was of a not Serializable type.

Having checked that the above attributes both show up as unavailable in the jconsole, I jumped to that conclusion, which, as you correctly stated, is not right.

Using twiddle I was able to obtain some results for the EJB3 InvokeStats attribute but trying to do the same for the EJB2 attribute yielded:

[metlos@localhost bin]$ ./twiddle.sh -s 127.0.0.1 -u admin -p admin get jboss.management.local:EJBModule=mdbsessionpoolclear.jar,J2EEApplication=null,J2EEServer=Local,j2eeType=MessageDrivenBean,name=Mdb stats
11:25:52,750 ERROR [Twiddle] Exec failed
java.lang.reflect.UndeclaredThrowableException
        at $Proxy0.getAttributes(Unknown Source)
        at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:168)
        at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:306)
Caused by: java.lang.ClassNotFoundException: org.jboss.management.j2ee.statistics.MessageDrivenBeanStatsImpl (no security manager: RMI class loader disabled)
        at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
        at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
        at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
        at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
        at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
        at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
        at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.util.ArrayList.readObject(ArrayList.java:593)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)
        at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)
        at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
        at java.rmi.MarshalledObject.get(MarshalledObject.java:142)
        at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:134)
        at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
        at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
        at org.jboss.jmx.connector.invoker.client.InvokerAdaptorClientInterceptor.invoke(InvokerAdaptorClientInterceptor.java:66)
        at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
        at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
        at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
        ... 3 more


I'm not sure what that exactly means and if it can be worked around (possibly this is an unmarshalling issue that could be solved by adding an appropriate jar on the RHQ plugin's classpath, but as I said, I need to work more on this).

Thanks Larry for looking at this with more rigour than I originally did.

Ok, so upon closer inspection of what's available both in the JMX of the AS server and in the JBoss AS RHQ plugin, we already have the data available in RHQ/JON:

EJB2:
=====

the JMX "stats" attribute exposes 3 statistics:
createCount, removeCount and messageCount

RHQ plugin defines 3 metrics for an EJB2 MDB:
Create Calls, Remove Calls and Method-Ready Beans

Even though it doesn't look like it, "Method-Ready Beans" in fact exposes the messageCount, which means, we expose all the stats there are available from JMX. We should look into renaming the 3rd metric to reflect what it actually measures.

EJB3:
=====
The InvokeStats is an object that exposes statistics for all types of EJB3 beans. It collects "Call Count", "Min Time", "Max Time" and "Total Time" *per method* (which, frankly, isn't that useful on an MDB that has a single method). This data is therefore difficult to expose as a metric and is instead exposed as an operation in RHQ.

Also note that the EJB3 MDBs deployed to an JBoss AS 4.x are discovered as "EJB3 Session Beans" in RHQ.

The trouble with EJB3 stats is that they are exposed as operation results and therefore can't be alerted on.

Maybe we should investigate the possibility of exposing them as calltime metrics.

Note that jboss-as5 plugin could also re-implement this because it, too, only exposes the stats as an operation.

Seems strange that this was implemented as an operation originally. Do we know why that decision was made? I would imagine that statistics like this would best be exposed as metrics/traits so that they can be made available in the metric/monitoring subsystems.

Ok, I should really check the facts thoroughly before I open my mouth.

Please disregard the previous comment, because, in fact, the stats *are* exposed as calltime data for EJB3s by the means of the "Method Invocation Time" metric.

Unfortunately, JON 2.4 doesn't offer the availability to alert on the calltime metrics. This is only present in RHQ 3 as an experimental feature.

The next major version of JON though is going to be able to alert on the calltime metrics.

The below table summarizes what's available in AS4 plugin:

          | Resource Type      | Stats as metrics          | Per-method stats 
-------------------------------------------------------------------------------
EJB2 MDB  | MessageDriven EJB  | createCount, removeCount, |   No
          |                    | messageCount *            |    
-------------------------------------------------------------------------------
EJB3 MDB  | EJB3 Session Bean  | createCount, removeCount, |   Yes
          |                    | availCount, maxCount,     |
          |                    | currentCount              | 
-------------------------------------------------------------------------------

* - the messageCount is currently confusingly called "Method-Ready Beans"

Larry, looks like this is a dead thread. Can we close this?

Agreed. Marking as NOTABUG as the requested metrics already existed under a different name and this issue is OUT_OF_DATE.