-
1. Re: Can I monitor available connections in 2.4.8?
wcleung9 Apr 14, 2005 9:41 PM (in response to davidchen)I want to know the solution too as I am facing exactly the same situation. I need to monitor the connection pool on JBoss 2.4.8 to see if it is the bottleneck of my web-app's performance.
I browsed the JMX web-console on port 8082. But it only provides configurations for the DataSourceLoader, such as max-pool-size, min-pool-size, timeout, etc. In other words, there are only initialization parameteres to set......
If JBoss 2.4.8 does not have such monitoring feature built-in, are there any free tool to do it? Or can I do it myself with least programing effort? -
2. Re: Can I monitor available connections in 2.4.8?
davidchen Apr 15, 2005 12:25 PM (in response to davidchen)If any one can clarify please. By the way, we stopped that monitor connection pool project and upgrade to jboss 3.2.6. However, I'm still interested in that topic.
David -
3. Re: Can I monitor available connections in 2.4.8?
wcleung9 Apr 29, 2005 11:05 PM (in response to davidchen)Just want to share my experience and hope that would help others.
Now I wrote my own class to do the monitoring job. I found that the Connection objects created by the datasource (org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl) are in fact org.jboss.pool.jdbc.xa.wrapper.XAConnectionImpl instances. XAConnectionImpl implements the interfaces javax.sql.PooledConnection and org.jboss.pool.PooledObject.
And these 2 interfaces fire events for listeners to catch. So I made use of the listeners API to monitor the connection activity.
I extended the datasource XADataSourceImpl. Everytime MyXADataSourceImpl creates a new Connection, it adds a javax.sql.ConnectionEventListener and a org.jboss.pool.PoolEventListener to the lister-list of the Connection object. Although these 2 listeners do not actually catch the connection-fetched event, they catch the connection-used and connection-closed events. And this is enough to virtually catch the connection-fetched event.
Well, I would say this is not a very good approach. It adds extra classes to the app server, and it might not apply to other apps using other DataSource classes. But it served my purpose with least impact to the app (just put the extra jar under the classpath, and switch the DataSource in jboss.jcml).
Any better solution would still be appreciated.