Upgrade from commons-pool 1.4 to commons-pool 1.5 due to deadlocks

[Warren.Menezes]

Hi Isomorphic

We have recently started facing deadlock issues on our server. I have attached a part of the thread dump with more details on the deadlock.
We feel this is linked to a bug in the commons-pool jar. Please read through the comments in
https://issues.apache.org/jira/browse/DBCP-44
https://issues.apache.org/jira/browse/DBCP-65
https://issues.apache.org/jira/browse/DBCP-270
https://issues.apache.org/jira/browse/POOL-125
They claim to have fixed it in the 1.5 release.

We faced this issue with SmartGWT version v8.3p_2013-05-05/Enterprise Deployment 2013-05-05 and have now upgraded to version v9.0p_2013-07-14/Enterprise Deployment 2013-07-14.
Is it safe to upgrade our commons-pool library to version 1.5 since it is suggested that we use the jars packaged by SmartGWT?
Are there any plans to update the commons-pool jar that is packaged with the newer smartGWT releases?

Thanks

[Isomorphic]

We've never seen a deadlock like this even in high load environments, so it might actually be an application-level issue rather than something triggered by bugs in DBCP.

In general, you can use a more recent version of any library that has maintained backwards compatibility. So upgrading DBCP to see if it fixes your problem seems like a reasonable troubleshooting step.

In the meantime we'll look at whether upgrading regresses any of our internal tests.

Please do let us know if the DBCP upgrade solved your issue.

[Isomorphic]

We just noticed you're using 8.3. 9.0 and later actually use dbcp 1.6 by default, so we'd recommend just going to that version.

[Warren.Menezes]

Hi Isomorphic

Our application has a lot of long running queries. We have started facing this issue recently when the number of users of our application increased. We feel the deadlocks may be linked to the large number of users running long queries.

These are the settings we use for our connection pool. Are these fine or do you suggest something different?

sql.Oracle.pool.maxActive:20
sql.Oracle.pool.maxIdle:10
sql.Oracle.pool.maxWait:5000
sql.Oracle.pool.minEvictableIdleTimeMillis:5000
sql.Oracle.pool.numTestsPerEvictionRun: 5
sql.Oracle.pool.timeBetweenEvictionRunsMillis: 10000

sql.Oracle.pool.validationQuery:select 1 from dual
sql.Oracle.pool.testOnBorrow:true
sql.Oracle.pool.minIdle:0

We are in the process of updating our commons-pool to 1.6 and commons-dbcp to 1.4. We were never able to reproduce the deadlocks in our testing environment and it will take time before we can validate if these changes make a difference when the app is live. I will keep you posted.

Thanks

[Isomorphic]

Again, we've never seen an issue, so we can't really comment. There's nothing obviously wrong with those settings.

[Blama]

Hi Warren.Menezes,

did you replace the JAR? Did that work for you?
We do have similar problem right now (v12.0p_2019-03-23 on Apache Tomcat Version 9.0.17). ( Isomorphic: I'll create a separate thread with some investigations for this)

Isomorphic: In #3 you write that 9.0 (=SmartGWT 4.0, IIRC) uses dbcp 1.6. I'm now on 12.0 and the shipped JAR is commons-dbcp-1.4.jar. Is this correct? Did you ever ship 1.6 and switched back to 1.4? If so, do you know why?

Thank you & Best regards
Blama

[Blama]

Hi @all,

sorry, you are writing about pool with the version numbers, I was writing about dbcp. 12.0p already uses pool-1.6.

This still might be related (in #4 Warren.Menezes also mentions his DB-settings), but definitely no fix via drop-in replacement is possible.

Best regards
Blama