Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap connection (#43)

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap connection (#43)


Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>, "" <>
  • Subject: RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap connection (#43)
  • Date: Tue, 14 Jul 2015 14:23:39 +0000
  • Accept-language: en-US

Just curious, it is ok for the fix to go into 2.2.1 patch? I.e. will you be
able to upgrade to this version to get the fix? Or must you have it in 2.1?

Thanks
Chris

-----Original Message-----
From: Chris Hyzer
Sent: Monday, July 06, 2015 9:57 AM
To:
'';


Subject: RE: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap
connection (#43)

Thanks for debugging, I will fix this for you

Thanks,
Chris

-----Original Message-----
From:


[mailto:]

Sent: Monday, July 06, 2015 9:52 AM
To:
;
Chris Hyzer
Subject: Re: [grouper-dev] RE: [grouper] Grouper 2.1.5 loses track of ldap
connection (#43)

Hi,

I'm a colleague of Hans and took over the problem we are having with invalid
Ldap connections not being cleaned up after a Ldap restart.

When I look into the source code (tag GROUPER_2_1_5) then I can't see how your
suggestion could work. Basically the LdapSourceAdapter reads the properties
file specified by ldapProperties_file. It uses the properties file to read the
credentials and the additional key-values related to tuning the Ldap pool
(e.g. edu.vt.middleware.ldap.pool.validateOnCheckOut) end up in
DefaultLdapFactory#config#additionalEnvironmentProperties

However when the pool is created (LdapSourceAdapter#initializeLdap line 291):

DefaultLdapFactory factory = new DefaultLdapFactory(ldapConfig);

try {
ldapPool = new SoftLimitLdapPool(factory);
ldapPool.initialize();
the SoftLimitLdapPool constructor used is the one where the factory is
supplied on the SoftLimitLdapPool and not the other constructor where also the
LdapPoolConfig is provided. As such the SoftLimitLdapPool is initialized with
a new default LdapPoolConfig and the tuning properties specified in the
ldapProperties_file are never used. I debugged our test environment and
confirmed this.

Maybe I'm missing something but I think using the single argument constructor
for the SoftLimitLdapPool with only the factory being provided and not the
LdapPoolConfig is a bug. Could you confirm this?

Again maybe I'm missing something, but when I examined the code I can't figure
out where the SoftLimitLdapPool being used could ever pick up the tuning
properties in the ldapProperties_file as it's creates a new default
LdapPoolConfig which does not validate anything and has a
DEFAULT_VALIDATE_ON_CHECKOUT of false.

Thanks,
Okke



Archive powered by MHonArc 2.6.16.

Top of Page