This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 566256 - Request for metrics on EJB3 MDB in the JBoss AS Plugin
Request for metrics on EJB3 MDB in the JBoss AS Plugin
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
1.3.1
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Preethi Thomas
:
Depends On: 680071
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-17 12:27 EST by dsteigne
Modified: 2014-05-27 15:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-27 15:41:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description dsteigne 2010-02-17 12:27:42 EST
Description of problem:
It looks like there are JBoss AS 4.x MBeans for both EJB2 and EJB3 MDBs, both of which expose method invocation stats.

EJB2 example
------------
MBean name: jboss.management.local:EJBModule=mdbsessionpoolclear.jar,J2EEApplication=null,J2EEServer=Local,j2eeType=MessageDrivenBean,name=Mdb
attribute name: stats
attribute type: javax.management.j2ee.statistics.Stats

EJB3 example
------------
MBean name: jboss.j2ee:jar=jboss-ejb3-tutorial-mdb.jar,name=DefaultedExampleMDB,service=EJB3
attribute name: InvokeStats
attribute type: org.jboss.ejb3.statistics.InvocationStatistics

Can these be exposed in the jboss-as plugin.
Comment 1 Lukas Krejci 2011-01-20 15:18:14 EST
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.
Comment 2 Larry O'Leary 2011-01-27 01:28:47 EST
(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.
Comment 4 Lukas Krejci 2011-01-27 08:50:10 EST
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.
Comment 5 Lukas Krejci 2011-01-27 10:38:39 EST
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.
Comment 6 Lukas Krejci 2011-01-27 10:59:04 EST
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.
Comment 7 Larry O'Leary 2011-01-27 12:24:38 EST
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.
Comment 8 Lukas Krejci 2011-01-27 12:46:06 EST
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"
Comment 9 Jay Shaughnessy 2014-05-27 14:42:11 EDT
Larry, looks like this is a dead thread. Can we close this?
Comment 10 Larry O'Leary 2014-05-27 15:41:04 EDT
Agreed. Marking as NOTABUG as the requested metrics already existed under a different name and this issue is OUT_OF_DATE.

Note You need to log in before you can comment on or make changes to this bug.