Commons Dbcp
  1. Commons Dbcp
  2. DBCP-260

borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2, 1.2.1, 1.2.2, 1.3, 1.4
    • Fix Version/s: 2.0
    • Labels:
      None
    • Environment:

      Windows XP, eclipse. JDK 1.6

      Description

      This bug is related to bugs #1, #38 & #102. Thought the bugs are closed, I think there is a (edge condition) scenario that is not handled properly:

      Config:
      10 active connections limit
      RemoveAbandoned set to 'on'
      RemoveAbandonedTimeout set to x (say 60 secs)

      Suppose 10 connections were borrowed and the 11 th request was issued, all within a time frame shorted then the timeout.

      The first 10 requests are in methods that do not properly release the connection.

      This means that the 11 th thread is waiting indefinitely until a notify is sent.
      The 'non releasing' threads the first 10 connections hence no notification is sent
      The 'garbage collection' is performed by the calling AbandonedObjectPool before calling the GenericObjectPool.borrowObject(...). This garbage collection will not be called again and the wait() will stay locked though some connections might be come available through timeout expiration.

      The quick n dirty workaround is to setMaxWait(...) but still I think a better solution will be along the lines of:
      1. Waiting for removeAbandonedTimeout secs
      2. Retry regular allocation

        Activity

        Hide
        Phil Steitz added a comment -

        What version of DBCP are you running?

        IIUC, this is really an enhancement request for AbandonedObjectPool, which is a (deprecated) DBCP class.

        Pool handles the notification correctly, but again assuming I understand the use case correctly, AbandonedObjectPool's removeAbandoned method will not get called unless and until another thread arrives to invoke borrowObject. This is a corner case for AbandonedObjectPool, which I think is best handled by the client by setting maxWait.

        Show
        Phil Steitz added a comment - What version of DBCP are you running? IIUC, this is really an enhancement request for AbandonedObjectPool, which is a (deprecated) DBCP class. Pool handles the notification correctly, but again assuming I understand the use case correctly, AbandonedObjectPool's removeAbandoned method will not get called unless and until another thread arrives to invoke borrowObject. This is a corner case for AbandonedObjectPool, which I think is best handled by the client by setting maxWait.
        Hide
        Meir Shahar added a comment -

        Hi Phil,

        I use DBCP 1.2.2.

        You got it correctly and it is a corner condition, this would obviously not happen if a periodical cleaner thread would remove idle connections. As far as I am concerned, the workaround is fine. I submitted the bug to raise the issue and point at the location of the problem. If you decide to keep things as they are, at least other users can be aware of this issue.

        Also, the third faq item on the wiki page (http://wiki.apache.org/jakarta-commons/DBCP) states that the abandoned pool, though deprecated, is still active and will be supported in future versions.

        Show
        Meir Shahar added a comment - Hi Phil, I use DBCP 1.2.2. You got it correctly and it is a corner condition, this would obviously not happen if a periodical cleaner thread would remove idle connections. As far as I am concerned, the workaround is fine. I submitted the bug to raise the issue and point at the location of the problem. If you decide to keep things as they are, at least other users can be aware of this issue. Also, the third faq item on the wiki page ( http://wiki.apache.org/jakarta-commons/DBCP ) states that the abandoned pool, though deprecated, is still active and will be supported in future versions.
        Hide
        Phil Steitz added a comment -

        This should be fixed when AbandonedObjectPool is moved to pool. Leaving open until move, at which time this should become a pool issue.

        Show
        Phil Steitz added a comment - This should be fixed when AbandonedObjectPool is moved to pool. Leaving open until move, at which time this should become a pool issue.
        Hide
        Mark Thomas added a comment -

        I have confirmed that this is fixed in Pool2 / DBCP2 and I have added the test case that confirms it to Pool2.

        Show
        Mark Thomas added a comment - I have confirmed that this is fixed in Pool2 / DBCP2 and I have added the test case that confirms it to Pool2.

          People

          • Assignee:
            Unassigned
            Reporter:
            Meir Shahar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development