JBAS-1808 - MCF MBeans

[adrian.brock]

As per the RAR MBeans we should optionally allow an MCF to expose
its own management/statistics.

This could just be config in the -ds.xml

Finally, the original requirement is to expose prepared statement cache stats.
Since this is at the connection level, this would either require

* making the ManagedConnection an MBean, which is possible since ManagedConnections
are relatively long lived.
* forcing the MCF MBean to consolidate connection stats

This will be so much easier when we have decorators :-)

[vickyk]

* making the ManagedConnection an MBean, which is possible since ManagedConnections
are relatively long lived.
* forcing the MCF MBean to consolidate connection stats

I have started looking at JBAS-1808 and would like to get some pointers regarding the implementation details
* making the ManagedConnection an MBean
1) When ManagedConnection is created it should be registered as MBean.
2) The ManagedConnection MBean will have to expose the management/statistics data.
3) Finally we need management/statistics related operations defined in MCF MBean which will look/consolidate the data. The MCF MBean being referred here is org.jboss.resource.connectionmanager.RARDeployment .

The other option
* forcing the MCF MBean to consolidate connection stats
The org.jboss.resource.connectionmanager.RARDeployment can be updated to pull all the PreparedStatementCache data from the associated MCF instance which is available through getMcfInstance() method .
The connection creation/destruction in MCF should update the PreparedStatementCache related data in the MCF implementation(LocalManagedConnectionFactory Or XAManagedConnectionFactory) , this needs to be implemented .
This option looks complex .

Looking at the original requirement I could think of pulling the PreparedStatementCache from the JbossManagedConnectionPool MBean per DataSource.
As per the original requirement we need to
1) Get all the ManagedConnection from the Pool.
2) Find out the PreparedStatementCache associated with these ManagedConneciton in the pool.

Here I see the related data being pulled from the JbossManagedConnectionPool/InternalManagedConnectionPool .

[vickyk]

"vickyk" wrote:

Looking at the original requirement I could think of pulling the PreparedStatementCache from the JbossManagedConnectionPool MBean per DataSource.
As per the original requirement we need to
1) Get all the ManagedConnection from the Pool.
2) Find out the PreparedStatementCache associated with these ManagedConneciton in the pool.

Here I see the related data being pulled from the JbossManagedConnectionPool/InternalManagedConnectionPool .

Adrian , I have tried this option .

I tried this code in the JbossManagedConnectionPool

+ public Object listUnderlyingNativeConnectionStatistics()
+ {
+ String statistics = "";
+ for(Iterator iter = subPools.values().iterator(); iter.hasNext();)
+ {
+ SubPoolContext subContext = (SubPoolContext)iter.next();
+ InternalManagedConnectionPool internalPool = subContext.getSubPool();
+ java.util.ArrayList cels = internalPool.getCELs();
+ int connectionCount = cels.size();
+ for(int i=0;i<connectionCount;i++)
+ {
+ ConnectionListener cl = (ConnectionListener) cels.get(i);
+ javax.resource.spi.ManagedConnection mc = cl.getManagedConnection();
+ if (mc instanceof org.jboss.resource.statistic.JBossConnectionStatistics)
+ {
+ org.jboss.resource.statistic.JBossConnectionStatistics stats = (org.jboss.resource.statistic.JBossConnectionStatistics)mc;
+ statistics += stats.listConnectionStats();
+ }
+ else
+ {
+ statistics = mc + " does not implement org.jboss.resource.statistic.JBossConnectionStatistics , <br><font color='red'>So this Operation is Not available!!!</font> ";
+ break;
+ }
+ }
+ }
+ return statistics;
+ }

With this approach we can expose the underlying connection specific statistics in the JbossManagedConnectionPool MBean .
The required statistics should be formated in the the listUnderlyingNativeConnectionStatistics() method and the ManagedConnection should implement JbossConnectionStatistics .
Before I go fully on this I would like to know your opinion on this .

[adrian.brock]

Vicky, for such trivial changes in general you should just do it.
Silence means approval. :-)

However in this case, you've got a thread safety issue.

If the cels really are an ArrayList then not accessing it in a synchronized block
will produce a ConcurrentModificationException when the pool changes.

Exposing an AarrayList isn't very good api anyway.

The method in InternalManagedConnectionPool should look something like this:

// The method should be package protected and just specify a Set
Set<ConnectionListener> getConnectionListeners()
{
 // Avoid concurrency issues with the rest of the pool
 synchronized (cls)
 {
 // "Clone" the internal collections inside the synchronized block to avoid concurrency issues
 Set<ConnectionListener result = new HashSet<ConnectionListener>();
 result.addAll(cls); // The connections in the pool
 result.addAll(checkedOut); // The connections being used by applications
 return result;
 }
}

[vickyk]

Vicky, for such trivial changes in general you should just do it.
Silence means approval. :-)

Yes , I guessed the silence would mean approval.
In your earlier approached you have never described getting the ManagedConnections from InternalManagedConnectionPool so that keep me thinking hard :) , as you did mentioned the trivial approach .
I am going to consider the thread safety issue , thanks !!!