-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Ric,

On 10/25/14 9:06 PM, Ric Bernat wrote:
> Thanks. That makes sense. Pooling for the duration of that single
> web service call is not our main goal. However, JAX-RS allows me
> to persist objects in memory across web service calls, so I can
> keep a collection of DataSource instances (e.g., by database name,
> in a ConcurrentHashMap). No problem keeping DataSource instances in
> memory for an extended period of time, is there?
> 
> btw, I have worked with Microsoft tools in the past, including SQL 
> Server ADO.NET connection pooling. There, you get one connection
> pool per connection string, regardless of what object instance you
> use to instantiate your connection objects. That is doubtlessly why
> I came to Tomcat connection pooling with a 
> connection-URL-equals-connection-pool mindset.
> 
> On a tangent, I am very eager to monitor Tomcat connection pooling
> so that I can see what is going on with the connection pools. To
> that end, I have configured both the JMXProxyServlet (via the
> "manage" webapp), and PSI Probe. And I have set 
> poolProperties.setJmxEnabled(true). However, neither of these 
> monitoring tools let me see any information about Tomcat
> connection pool state. Perhaps these tools required that I JNDI to
> configure my database connections, and cannot monitor connection
> pools created via Java code?
> 
> Unless I am using those two monitoring tools incorrectly (quite 
> possible), and they really do offer a view of connection pool
> state, it seems that my only choice is to configure JMX monitoring,
> which seems non-trivial. (I am assuming that JMX will give me a
> view of connection pool state.)
> 
> Or perhaps I should go the JNDI route (guessing that my two
> current monitoring apps can show connection pooling information
> for JNDI-created connection pools). However, since we create
> databases at runtime, I'm not sure that I would be able to create
> JNDI declarations for just-created databases on the fly.

I haven't used non-JNDI connection pools, so I'm not absolutely sure
about this.

- From the tomcat-pool documentation[1]:
"
The connection pool object exposes an MBean that can be registered. In
order for the connection pool object to create the MBean, the flag
jmxEnabled has to be set to true. This doesn't imply that the pool
will be registered with an MBean server, merely that the MBean is
created. In a container like Tomcat, Tomcat itself registers the
DataSource with the MBean server, the
org.apache.tomcat.jdbc.pool.DataSource object will then register the
actual connection pool MBean. If you're running outside of a
container, you can register the DataSource yourself under any object
name you specify, and it propagates the registration to the underlying
pool. To do this you would call
mBeanServer.registerMBean(dataSource.getPool().getJmxPool(),objectname).
Prior to this call, ensure that the pool has been created by calling
dataSource.createPool().
"

So, the JMX bean is being created, but it's not registered with the
JMX server so you can't see the bean remotely. You'll have to register
it yourself as described above.

That one-line call isn't entirely straightforward, so let me refer you
to a presentation on monitoring Tomcat via JMX which shows you how to
register your own beans. (In your case, the bean exists already, so
you'll just be registering the bean from tomcat-pool):
http://people.apache.org/~schultz/ApacheCon%20NA%202014/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf

Hope that helps,
- -chris

[1] http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#JMX
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUTPLAAAoJEBzwKT+lPKRYJ1wP/0FhZoL/VgASr3rKUps61ocX
SV1DKdwtUalt8f++MuPODJflBEkxsjeO6tmHLlHi1Ew5yCUVDz6/GQFPJDM0j16v
tCv0veB6H+5AR4AcSvIvHZLdwnocYN3NY0mIAuxHCwfMNDxgZ5fg6m6r05/7lc6h
Q0ZZyIEpx3NT1DpwJ6Qy/4junQ0IkwkVgFaB2NY07M9Ec00uujbn2eMdFiqk0LEo
P/qTPTui0V8Y3Pe45NSwgjWzO66O6CrwB2lpt5gZyOcdQ4FQ8RCkaUw4KyPB6xjk
cbFl+Lxz7PnpXOu6OTLrVEDbhvevPKdrYUl4wk7/GL5aeIextY4pfV8VeLl6eddj
lu5gKNV0kEjgt8j+6HUP4ItGQVKxndYWBm7+TCSdAb+Md0/X9TuJISmYinniK6Mw
93ygRx2M9oSSiqR+LCUz+fXDkDcRNpEMY196OI2T077Gxyyejjsn6238f9p/Uuwr
5Q+9LA8jqHgE00bXl03ZMa8Yq5mc15W+OVG08rPqE7FQmSV6sezTClct+SJ9Jj73
vxoEDFTa0aLQu9SWaZ2V/3md0ydqeVqzBDwehSo6W33+3cau+xIG8+Kkv7RDlQJr
QPHCDAnpHmMmbcD4Lwleuua8mxqsq+RGw1X9j4aJB8cTroEvMIvd2DhW70W9O0Fm
+PWW7OpOvMQ3NffY01ZF
=bYDS
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to