Bug 1017119 - LDAP context mis-close in LDAPIdentityStoreImpl
LDAP context mis-close in LDAPIdentityStoreImpl
Status: VERIFIED
Product: JBoss Enterprise Portal Platform 6
Classification: JBoss
Component: PicketLink (Show other bugs)
6.1.0
Unspecified Unspecified
medium Severity high
: DR01
: 6.1.1
Assigned To: Boleslaw Dawidowicz
Dominik Pospisil
FixAvail
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-09 05:37 EDT by Toshiya Kobayashi
Modified: 2014-02-11 00:19 EST (History)
6 users (show)

See Also:
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.
Story Points: ---
Clone Of: 1017111
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker PLIDM-44 Major Resolved LDAP context mis-close in LDAPIdentityStoreImpl 2014-07-21 04:43:22 EDT

  None (edit)
Description Toshiya Kobayashi 2013-10-09 05:37:48 EDT
+++ 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 05:53:15 EDT
Tom Fonteyne <tfonteyn@redhat.com> 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 11:52:06 EDT
Marek Posolda <mposolda@redhat.com> updated the status of jira PLIDM-44 to Resolved
Comment 4 JBoss JIRA Server 2013-10-14 11:52:06 EDT
Marek Posolda <mposolda@redhat.com> 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 16:51:20 EST
PLIDM upgraded to 1.4.4 in 3.6.x branch.
Comment 6 Tomas Kyjovsky 2013-12-18 11:24:15 EST
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@6e73226c.get(): 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@6e73226c.get(): 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@6e73226c.get(): after; size: 2
17:13:30,466 ERROR [stderr] (http-/127.0.0.1:8080-4) com.sun.jndi.ldap.pool.Connections@6e73226c.release(): 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@6e73226c.release(): 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@6e73226c.release(): notify; size: 2
...
Comment 7 Tomas Kyjovsky 2013-12-18 11:48:14 EST
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 17:37:45 EST
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 03:30:43 EST
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.