Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

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

    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
    Attached Files

    #2
    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.

    Comment


      #3
      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.

      Comment


        #4
        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?
        Code:
        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

        Comment


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

          Comment


            #6
            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

            Comment


              #7
              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

              Comment

              Working...
              X