aries.xa.poolMaxSize not enforced when using JDBC driver from OSGi Service Registry

Solution Verified - Updated -

Environment

  • JBoss Fuse 6.2.1

Issue

We have a Blueprint bundle that exports a JDBC driver into the OSGi Service Registry with e.g. these properties

<service interface="javax.sql.XADataSource" ref="mysql-ds">
  <service-properties>
    <entry key="osgi.jndi.service.name" value="jdbc/mysql-ds" />
    <entry key="datasource.name" value="mysql-ds" />
    <entry key="aries.xa.name" value="mysq-ds" />
    <entry key="aries.xa.pooling" value="true" />
    <entry key="aries.xa.poolMinSize" value="0" />
    <entry key="aries.xa.poolMaxSize" value="5" /> 
  </service-properties>
</service>

In particular we configure aries.xa.poolMaxSize=5.
However during a load test we see far more JDBC connections being created to the database that the configured poolMaxSize.

What is causing this?

Resolution

Install the connector feature:

# non Fabric
features:install connector

## Fabric
fabric:profile-edit --feature connector <your-profile-name>

Root Cause

In JBoss Fuse 6.2.1 we do not deploy the bundle

mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/2.1.1

out-of-the-box any more. Older versions of JBoss Fuse had this bundle deployed out-of-the-box.
This bundle is required for wrapping your JDBC driver into a pooling enabled driver, so that aries.xa.poolMaxSize=5 gets enforced.

Rather than manually installing this bundle, please install the connector feature instead.

Diagnostic Steps

Running osgi:ls on the bundle that exports the JDBC DataSource will not help to tell if the JDBC driver is wrapped in a pooled driver or not.
The output of osgi:ls will still list the aries.xa service properties, even though they cannot be enforced as the JDBC driver is not wrapped in a pooled driver.

On container startup there should be the following log entry written if the JDBC driver is wrapped in a pooled driver:

INFO  | loyer-3-thread-1 | Activator | 395 - org.apache.aries.transaction.jdbc - 2.1.1 | Wrapping DataSource [javax.sql.XADataSource]

If its not wrapped the above line of logging would be missing.

Another way to verify is to take a heap dump of the Karaf JVM and using the OQL language check for an instance of any of these classes

  SELECT * FROM INSTANCEOF org.apache.aries.transaction.jdbc.internal.Activator
  SELECT * FROM INSTANCEOF org.apache.aries.transaction.jdbc.internal.ConnectionManagerFactory
  SELECT * FROM INSTANCEOF org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
  SELECT * FROM INSTANCEOF org.apache.aries.transaction.jdbc.internal.ConnectionManagerFactory
  SELECT * FROM INSTANCEOF org.tranql.connector.jdbc.TranqlDataSource
  SELECT * FROM INSTANCEOF org.apache.aries.transaction.jdbc.internal.ManagedDataSourceFactory
  SELECT * FROM INSTANCEOF org.apache.geronimo.connector.outbound.ManagedConnectionInfo

All of these classes would have to be instantiated if the JDBC driver is wrapped correctly.
But no instances of the above classes should be found if not.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments