JBAS-2705: List Sub Pool Statistics

[weston.price]

TODO:

Add listStatistics() method to JBossManagedConnectionPoolMBean which in turn delegates to underlying ManagedConnectionPool implementation. In turn, each SubPool (i.e. OnePool, PoolByCri etc, etc) should implement their own version of displaying the underlying subpool statistics.

As a result, JMX statistics for JBossManagedConnnectionPool should change to reflect that the statistics show for things like currentConnectionCount etc, etc. are reflectiive of ALL sub pools together. This probably amounts to just renaming the JMX operations to something more appropriate:

getCummulativeCountDestroyed
getCummulativeMaxConnectionInUseCount

[weston.price]

I would like to refactor some of the JBossManagedConnectionPool stuff. While I have the patient open in implmenting this task, would it make sense to break the pool, connectionfactory, etc, etc into their own packages.

At the very least, I want to pull out the BasePool-SubClasses out of the MBean as static classes and give them their own source file.

If anything, I find this easier to read.

[adrian.brock]

Work on the prototype instead.

1) There is little point refactoring something that already works and breaking everybody
while you do it.

2) We need this old implementation for "backwards compatibility" reasons
i.e. people that have stuff working, but only by luck. They are using something
undocumented or unintentional.

3) Although we stopped supporting the direct JMX deployment in 3.2.x
that will likely be some people still using it.

[weston.price]

Agreed.

I had forgotten about 3.2 deployments.

[weston.price]

In working on this 'stat's stuff, should I integrate the work I have done thus far into the current JCA implementation and then retro-fit into the jboss-jca stuff, or should I primarily focus on the prototype.

I think it would be beneficial to have some form of statistics for work management in a new 4.0.x release, but I am not married to this idea.

I implemented both the SubPoolStats as well as a working model for the stats management on WorkManagement (more on this is seperate thread).

[adrian.brock]

You can apply it to both. Just don't break compatibilty, e.g. if somebody else
implements the MangedConnectionPool interface.

[weston.price]

I don't see how I can't implement this an not break some existing compatiblity without loosening up the scoping on the ManagedConnectionPool itself. In the present implementation the JBossManagedConnectionPool MBean exposes the listStatistics() method which in turn just delegates to the ManagedConnectionPool to list sub pool statistics. The JBossManagedConnectionPool holds a reference to the MCP via the interface. To allow for exposing these statistics, either a method has to be put on the interface, or I am going to have to cast to the BasePool. The latter would seem to me to be the more obtrusive and hackish approach.

[adrian.brock]

class BasePool implements ManagedConnectionPool,
SomeNewStatisticsInterfaceExtension

Don't change the MCP interface.

Then in JBossManagedConnectionPool

if (pool instanceof SomeNewStatisticsInterfaceExtension)
 pool.extension();
else
 // noop

[weston.price]

Can do.

Also, I want to add a few new statistics:

a) Average use time
b) Error count

etc, etc.

[weston.price]

But again, the solution:

if (pool instanceof SomeNewStatisticsInterfaceExtension)
pool.extension();
else
// noop

Will required a cast to support being that the JBossManagedConnectionPool only references ManagedConnectionPool. Again, it's just a variant of the other approach.

But yes, this would be a decent approach to not break the ManagedConnectionPool interface.

[weston.price]

Also, I would like to backport this to 4.0.4...however, given time constraints we can adjust the JIRA task to reflect that it will be availabe in 5.0.

[weston.price]

One more question:

Should we consider changing the MBean interface to reflect that the current stats being reported are cummalative versus per sub Pool?

Example:

CreatedConnectionCount - TotalCreatedConnectionCount

If we don't do something like this, I can already anticipate the questions.

[adrian.brock]

There is no problem with changing JBossManagedConnectionPool to
do this

 /** The pooling strategy */
 private BasePool poolingStrategy;

The issue is with the other uses of ManagedConnectionPool
that are "pluggable", e.g. the injection into the connection manager.

[adrian.brock]

Please try to keep 4.0.x and 5.0.x in step.
It makes it easier to apply fixes.

But I'd say the JCA work in 4.0.4 is complete, so the changes should be only in
head until they can be applied to 4.0.5CR1

Don't change the management interface, that will break user code.
You can add new methods and deprecate the old ones.

[adrian.brock]

I think I mentioned this before, but it is worth repeating.

The raw statistics should be exposed as a serializable javabean.

Any html or xml formatting is additional for things that understand
how to process it.

The important thing is to give the user the underlying raw statistics
such that they can do there own procesing without having to break
out some wacky parser.