[jboss-jira] [JBoss JIRA] Resolved: (JBAS-8367) BasePool.emptySubPool() shuts down non-idle pool

[Shelly McGowan (JIRA)]

     [ https://jira.jboss.org/browse/JBAS-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-8367.
----------------------------------

    Fix Version/s:  6.0.0.M5
                       (was: 6.0.0.CR1)
       Resolution: Done


> BasePool.emptySubPool() shuts down non-idle pool
> ------------------------------------------------
>
>                 Key: JBAS-8367
>                 URL: https://jira.jboss.org/browse/JBAS-8367
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: James Livingston
>            Assignee: Jesper Pedersen
>             Fix For:  6.0.0.M5
>
>         Attachments: JBAS-8367.patch
>
>
> org.jboss.resource.connectionmanager.BasePool.emptySubPool() will shut down the per-subject or per-criteria subpool if it is idle, following the change in JBAS-5929 to reduce memory usage.
> It determines if the sub-pool is idle by using isEmpty(), however that only checks whether there are connections in the pool and does not look at checked out connections. So if all the connections from a pool are checked out, it will be shut down and the in-use connections destroyed when they are returned.
> This can manifest as a problem if a connection if during a transaction a 1PC resource is used twice, and the pool is shutdown before the second use because it has no connection that are not in use but have not reached the idle time.
> I haven't managed to produce a simple test case for this yet, however a complex application which triggers it right after the IdleRemover runs works correctly with any of these changes:
> 1) On AS 5.0.0 (which doesn't have  JBAS-5929) instead of 5.1.0
> 2) Using datasource settings which mean it uses OnePool (which overrides emptySubPool to do nothing) instead of PoolBySubject
> To trigger it will require:
> 1) PoolBySubject, PoolByCri or PoolBySubjectAndCri to be used
> 2) an idle timeout set
> 3) a 1 phase resource
> 4) a transaction which uses that 1PC resource twice
> 5) the idle timeout to run after the first getConnection() call but before the second.
> I believe that it should check whether there are any connections checked out and not shutdown the pool in that case since it is not idle.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira