Bug 1017119 - LDAP context mis-close in LDAPIdentityStoreImpl
Summary: LDAP context mis-close in LDAPIdentityStoreImpl
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: PicketLink
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: DR01
: 6.1.1
Assignee: Boleslaw Dawidowicz
QA Contact: Tomas Kyjovsky
URL:
Whiteboard: FixAvail
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-09 09:37 UTC by Toshiya Kobayashi
Modified: 2019-01-01 03:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
It was discovered that in certain scenarios, a duplicated ldapCtx.unbind(jndiName); in LDAPIdentityStoreImpl caused LDAP connections not to be released properly. This caused the size of the connection pool to increase, and could have lead to the LDAP connection pool exceeding it's upper size limit. The fix implements enhancements to Picketlink IDM 1.4.4.Final, which opens LDAP connections in case they are required and closes the threads correctly after work completes. This fixes the originally reported connection leaks in the LDAP connection pool.
Clone Of: 1017111
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker PLIDM-44 0 Major Resolved LDAP context mis-close in LDAPIdentityStoreImpl 2014-07-21 08:43:22 UTC

Description Toshiya Kobayashi 2013-10-09 09:37:48 UTC 
+++ This bug was initially created as a clone of Bug #1017111 +++

Platform BZ for https://issues.jboss.org/browse/PLIDM-44

Steps to reproduce: Please see "Steps to Reproduce:" in PLIDM-44
Comment 1 JBoss JIRA Server 2013-10-09 09:53:15 UTC 
Tom Fonteyne <tfonteyn> made a comment on jira PLIDM-44

It's the line:

  ldapCtx.unbind(jndiName);

which appears twice in that class, that should be removed. An unbind explicitly says to close the connection, instead of simply putting it back in the pool.
Comment 3 JBoss JIRA Server 2013-10-14 15:52:06 UTC 
Marek Posolda <mposolda> updated the status of jira PLIDM-44 to Resolved
Comment 4 JBoss JIRA Server 2013-10-14 15:52:06 UTC 
Marek Posolda <mposolda> made a comment on jira PLIDM-44

Fixed by commit https://github.com/picketlink/picketlink-idm/commit/90624614537c560b0df6b296c0c901c932468056
Comment 5 Peter Palaga 2013-11-26 21:51:20 UTC 
PLIDM upgraded to 1.4.4 in 3.6.x branch.
Comment 6 Tomas Kyjovsky 2013-12-18 16:24:15 UTC 
I just tried with JPP-6.1.1.DR02 and GateIn master and the problem (as described in PLIDM-44 steps to reproduce) is still there.

When I configure the server for LDAP and enable the debug option for the LDAP store, I can see tons of errors in log during startup and on user login:

...
17:13:30,464 ERROR [stderr] (http-/127.0.0.1:8080-4) LdapPoolManager: using authmech: simple
17:13:30,464 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Pool@4baec744 {rhds01.mw.lab.eng.bos.redhat.com:389:::null:uid=epp,dc=jboss,dc=com=com.sun.jndi.ldap.pool.ConnectionsRef@433223bd}.get(): rhds01.mw.lab.eng.bos.redhat.com:389:::null:uid=epp,dc=jboss,dc=com
17:13:30,464 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Pool@4baec744 {rhds01.mw.lab.eng.bos.redhat.com:389:::null:uid=epp,dc=jboss,dc=com=com.sun.jndi.ldap.pool.ConnectionsRef@433223bd}.size: 1
17:13:30,465 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Pool@4baec744 {rhds01.mw.lab.eng.bos.redhat.com:389:::null:uid=epp,dc=jboss,dc=com=com.sun.jndi.ldap.pool.ConnectionsRef@433223bd}.get(): size after: 1
17:13:30,465 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections(): before; size: 2
17:13:30,465 ERROR [stderr] (http-/127.0.0.1:8080-4) ConnectionDesc.tryUse() com.sun.jndi.ldap.LdapClient@167797a9 idle
17:13:30,465 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections(): use com.sun.jndi.ldap.LdapClient@167797a9; size: 2
17:13:30,465 ERROR [stderr] (http-/127.0.0.1:8080-4) Use com.sun.jndi.ldap.LdapClient@167797a9
17:13:30,465 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections(): after; size: 2
17:13:30,466 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections(): com.sun.jndi.ldap.LdapClient@167797a9; size: 2
17:13:30,466 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections(): release com.sun.jndi.ldap.LdapClient@167797a9; size: 2
17:13:30,466 ERROR [stderr] (http-/127.0.0.1:8080-4) Release com.sun.jndi.ldap.LdapClient@167797a9
17:13:30,466 ERROR [stderr] (http-/127.0.0.1:8080-4) ConnectionDesc.release() com.sun.jndi.ldap.LdapClient@167797a9 busy
17:13:30,466 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections(): notify; size: 2
...
Comment 7 Tomas Kyjovsky 2013-12-18 16:48:14 UTC 
Sorry, I missed the point of the problem, which was an inappropriate increase in the number of idle LDAP connections. After further testing this issue seems to be fixed.
Comment 8 Jared MORGAN 2014-02-04 22:37:45 UTC 
This issue was marked as a known issue, however the latest comments suggest the issue has been fixed.

The Doc Text for release notes needs to be modified, if the issue is to be included in the RHJP 6.1.1 Release Notes.

I've had a go at making the Cause and Consequence info, so please check this and add the fix details and the end result, and we should be good to go.
Comment 9 mposolda 2014-02-05 08:30:43 UTC 
Hi Jared,

the issue has been fixed and fix should be available in RHJP 6.1.1. Cheers, Marek
Note You need to log in before you can comment on or make changes to this bug.