Purge Policy for Connection Pools

[weston.price]

In helping a customer recently, I was thinking it might be relevant to consider implmeneting a type of 'purge policy' for the underlying connection pools. This concerns how to handle connection errors for a particular managed connection. Today, we only destroy the connection that fails. The policy, added as an element to *-ds.xml could allow for purging the entire pool of managed connections if one fails. This may be useful in the case that a single connection fails, and other connections that are existing should be cleaned up as well. I am primarily thinking in terms of situations where a 'pingDatabase' or validation check fails.

If anything, it would give finer grained control over the pool itself.

[adrian.brock]

It is an option, but I'm not sure why you would this?
Creating/Destroying connections is quite expensive compared
to using them for most things (that is the reason why they are pooled :-)

Seems to me that such a policy would mean a small problem
with one connection leads to lots of work getting done to recycle the
whole pool?

If you did do this, it would have to behave like the flush()
where already checked out connections get destroyed when
the application has finished with them.

[mamemc]

I was searching on something different and saw this thread. So here's a thought from an outside person.

I don't think that auto-flushing an entire pool is that useful, but putting the power into the hands of the users let's them decide for themselves. If it isn't a lot of work, then expose the functionality.

A more useful feature in my opinion would be time based pool cleanup -- if a connection has been in use for more than minutes then consider cleaning it up. Why? firewalls. We occassionally get long running connections whacked by our firewall settings. If there is no traffic over the connection in 60 minutes the firewall chops it and neither side is notified because it isn't a normal socket closure. These are much more painful to detect and cleanup, so having the pool terminate it would be useful to us. It would be also useful if the calling thread gets a java exception that something has been terminated.

Final thought. Similar functionality (time based cleanup) might be appropriate for the pooled invokers as well. I see time based growth in the number of ESTABLISHED connections using netstat to watch a pool. As I monitor the logs, I cannot account for the number of ESTABLISHED connections that exist compared with the number of distinct pooled invoker threads I see executing work. Time based cleanup of threads might resolve this. (And yes, I know there is a timeout property but that affects reads on the socket...what if something just goes south?).

[wmprice]

Time based cleanup is already provided by the IdleRemover for connections that have not been in use for a specific interval. Removing a connection that had been used within this time period would not really make a lot of sense, being that the connection is still 'live' and as far as JCA is concerned, 'valid'. In this case, the onus is really on the adapter to determine the semantics of this type of stuff.

In 4.0.5 there is a new feature to validate connections (JDBC) on a background thread which removes some of the performance hit that previously plagued validation.

Typically, you would never receive a connection that is not 'valid', as in your firewall scenario. For different types of connections, this can mean different things.

[weston.price]

Note, the purge policy features did indeed make it in as a patch. This behavior functionality needs to be carried forward for 4.0.6. I will update JIRA to reflect this as well.

[djr667]

It is an option, but I'm not sure why you would this?
Creating/Destroying connections is quite expensive compared
to using them for most things (that is the reason why they are pooled :-)

If a Oracle 9i server is restarted then all the pooled connections are dead and useless. A purge in this case would remove the need to restart the JBoss server.

We have tried, in our case, redeploying all web-apps and redeploying all *-ds.xml - but neither helps. It is unclear to me what would happen anyway to EJB3 injected datasources if you were to redeploy a *-ds.xml file.

Dave

[weston.price]

Please post your issue on the user forum. If you are indeed running into issues we should and would like to know about it.