Connection pool size exceeds <max-pool-size>

[vkorenev]

I have noticed that matchManagedConnections method of my ManagedConnectionFactory is never invoked. I examined the size of ManagedConnectionPool. It had too many connections open, though I limited them to 100.
I am closing connections after use and events are sent to registered ConnectionEventListeners.
Here is my *-ds.xml:
<?xml version="1.0" encoding="UTF-8"?>
<connection-factories>
<tx-connection-factory>
<jndi-name>jca/CBOSS</jndi-name>
<adapter-display-name>CBOSS Adapter</adapter-display-name>
<min-pool-size>0</min-pool-size>
<max-pool-size>100</max-pool-size>
<security-domain>CBOSSAdapterRealm</security-domain>
</tx-connection-factory>
</connection-factories>
Is it a bug or I have missed something?

[davidjencks]

It might be a bug, although I think there is a test for the max size working. Possibly the counting is off:-)

Are you including the closed connection handle in your ConnectionClosedEvent? this is essential.

Can you post some server log with the log level for org.jboss.resource turned up to trace showing what happens when you close a connection?

[vkorenev]

> Are you including the closed connection handle in your ConnectionClosedEvent? this is essential.

Yes, I do:
for (Iterator iter = listeners.iterator(); iter.hasNext();) {
try {
ConnectionEventListener listener
= (ConnectionEventListener) iter.next();
ConnectionEvent closedEvent = new ConnectionEvent(
this, ConnectionEvent.CONNECTION_CLOSED);
if (!handle.equals(connectionHandle)) {
logger.warn("Different connection");
}
closedEvent.setConnectionHandle(handle);
listener.connectionClosed(closedEvent);
} catch (NoSuchElementException e) {
logger.warn("Exception when closing", e);
}
}

[vkorenev]

I have posed a message 4 hours ago, but it is still not shown :-(

> Are you including the closed connection handle in your ConnectionClosedEvent? this is essential.

Yes:
for (Iterator iter = listeners.iterator(); iter.hasNext();) {
try {
ConnectionEventListener listener
= (ConnectionEventListener) iter.next();
ConnectionEvent closedEvent = new ConnectionEvent(
this, ConnectionEvent.CONNECTION_CLOSED);
if (!handle.equals(connectionHandle)) {
logger.warn("Different connection");
}
closedEvent.setConnectionHandle(handle);
listener.connectionClosed(closedEvent);
} catch (NoSuchElementException e) {
logger.warn("Exception when closing", e);
}
}

I limited the pool size to 10 connections. Then I opened and closed connection 40 times. I attach the log and the JBossManagedConnectionPool MBean view page.

[davidjencks]

Thank you for the log excerpt. The forum delay is worse than annoying.

I think what is happening is that each request for a connection is starting a new pool. This could happen if your adapter is supplying a ConnectionRequestInfo object with each request and these are not in fact supposed to be equal, or if the equals method is not implemented correctly on your object, or if there is a bug somewhere in jboss. Could you please clarify if your adapter supplies a cri object and if so check its equals method implementation?

Also, if this does not appear to be the problem could you set up without using a login module but a default user/pw and see what happens?

Many thanks
david jencks

[vkorenev]

I have changed equals method of my ConnectionRequestInfo in such a way that it now always returns true. The pool is not bloating anymore. But I do not think that a new pool must be created if ConnectionRequestInfos differ:
<JCA spec 1.0>
A resource adapter is required to implement the equals and hashCode methods defined on the ConnectionRequestInfo interface. The equality must be defined on the complete set of properties for the ConnectionRequestInfo instance. An application server can use these methods to structure its connection pool in an implementation specific way. Since ConnectionRequestInfo represents a resource adapter specific data structure, the conditions for equality are defined and implemented by a resource adapter.
</JCA spec 1.0>
If ConnectionRequestInfo differs, and I need a connection with other properties, I can match existing one in matchManagedConnection method an then change it state in ManagedConnection.getConnection method. I do not think that the following extract conflicts with it:
</JCA spec 1.0>
The equals and hashCode methods defined on both ManagedConnectionFactory and ConnectionRequestInfo facilitate the connection pool management and structuring by an application server.
</JCA spec 1.0>

Maybe I am mistaken :-)

[davidjencks]

Do you actually need to match connections based only one subject and ignoring the cri equality?

The current pool implementation lets you choose whether to pool based on Subject only, cri only, both subject and cri, and nothing. A "sub-pool" is created for each set of values of the selected criteria.

Up until now the *-ds.xml only maps to 3 of those: it does not let you pool based on Subject, ignoring the cri.

I'm about to change the xsl so that you can get Subject-only pooling criteria by specifying
<security-domain>myrealm</security-domain>

and subject and cri based pooling by

<security-domain-and-application>myrealm</security-domain-and-application>

If you can think of a better name for this element please suggest it.

Let me know if there are any problems.

[vkorenev]

Thank you for quick answers.

I am writing a resource adapter for a ERP system. There is a single logon to the database server (Oracle8i), and then each user must supply his own username an password to obtain an access to system functionality. They are stored in the database session using PL/SQL package variables and are set only by "login" package function. There are some other connection state properties that are set the same way (e.g. language, other preferences). There is also "relogin" package function enabling reuse of the open database connection by other user.

The requirements for scaling do not allow to keep an open connection for each user logged in. I found out that a pool of 40 connections is quite enough to support 300 concurrently working users. Furthermore it is too expensive to reinitialize user session for a randomly chosen database connection, while a connection pool may contain a suitable connection.

In this case the JCA specification encourages to use ManagedConnectionFactory.matchManagedConnections method to find the most suitable ManagedConnection, and then, if needed, to change it state in ManagedConnection.getConnection method.

Thus I need an opportunity to match connections ignoring both subject and cri equality. But I am using subject and cri both to initialize a new connection and to find the most suitable connection, and then to reinitialize it. IMHO all this fully complies with the JCA specification.

[vkorenev]

I have made a quick fix that works for me in the xsl:
ByNothing

IMHO it is not right to assume that the container does not support reauthentication if it is configured to use subject.

[davidjencks]

I don't understand your comment about reauthentication. If you pool based on Subject, you are indicating that you don't want to give the adapter the chance to reauthenticate any managed connections.

I think that even with ByNothing the current jboss pooling won't meet your needs very well. The current jboss pooling is designed with the idea that the pool can predict exactly which connection will be a good match based on equality of some combination of Subject and cri, so it only supplies a set of one connection to MatchManagedConnection. I think this is apt to give the best concurrency since you don't have to serialize matching, just requests getting candidates out of the pool.

If you are interested, you should be able to change InternalManagedConnectionPool to supply all the managed connections to the Match... method. Probably using a set rather than a list for the mc's would be a good idea. I think this should be fairly easy.

If you change and test the pool for this alternate strategy I'll see about exposing the choice of pool implementations.

[christian.harms]

Hi,

I've experienced the same problem as dicussed here: JBoss was creating a new managed connection every time a connection was requested.

What I use is ConnectionRequestInfo based pooling.

After this discussion gave me a better understanding about how connection pooling works I had a look on the JBoss source code to figure out what I did wrong:

You not only have to implement equals() on your CRI-class but also hashcode(). I have overlooked this in the JCA spec :-).

Maybe this is helpful for the next one reading the thread to solve problems.

Christian