Announcement Announcement Module
Collapse
No announcement yet.
Unexpected LDAP Pooling quirks Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unexpected LDAP Pooling quirks

    Hi
    I've configured pooling as below

    I then supplied the following -D options to a java app that loads beans that executes DAOs that use this ldaptemplate and contextSource.

    -Dcom.sun.jndi.ldap.connect.pool.timeout=300000 -Dcom.sun.jndi.ldap.connect.pool.debug=fine -Dcom.sun.jndi.ldap.connect.pool.initsize=10 -Dcom.sun.jndi.ldap.connect.pool.maxsize=10

    The app kicks off 20 threads per second that make ldap queries and everything works ok except pooling. From the pooling debug I can see the following behavior occuring.

    1) Initally on app start up 10 connections are created and used as expected.
    2) For a period of say 20 seconds these connections are used and released.
    3) Then I see abt 5 new connections being made and used.
    4) Then I see connections starting to expire. The expiring happens considerably before the pool.timeout has been reached.
    5) Then I see more creations, useage and release.
    6) This behavour happens through out the lifetime of the app which is only 2 mins.

    Problems
    1) I would expect there to be no expiring until after the pool.timeout has been reached.Which is 5 mins long after the app ends.
    2) I would expect never to see more than 10 connections because the max connections setting is 10 and the app ends before the expire time.
    3) Are there other parameters that need to be supplied to get pooling to work.
    Perhaps the auth type or protocol or something?
    4) This behavour seems unexpected and appears if the poolmanager has more than one pool eventhough all params are the same eg host, port, credentials, authtype?

    Can anyone confirm this behavour or at least tell me if I'm missing something.
    Note I've tested my -D options with really small values say 1 for max, init and timeout and they are actually read, the app will throw appropiate execptions.
    Regards
    D





    HTML Code:
    
    	<bean id="contextSource"
    		class="org.springframework.ldap.support.LdapContextSource">
    		<property name="urls" value="ldap://LDAP:391" />
    		<property name="pooled" value="true" />
                     <property name="userName" value="username" />
    		<property name="password" value="password" /> 
    		<property name="dirObjectFactory" value="org.springframework.ldap.support.DefaultDirObjectFactory" />
    	</bean>
    
    
    	<bean id="ldapTemplate"
    		class="org.springframework.ldap.LdapTemplate">
    		<constructor-arg ref="contextSource" />
    	</bean>
    
    
    Last edited by dellfy; Jun 12th, 2007, 09:22 AM.

  • #2
    First of all, I must make clear that Spring LDAP does not do anything special regarding the connection pooling. All we do is make sure contexts are closed properly, and in doing so, the underlying connection will be returned to the pool (unless it has other contexts associated with it). If the connection pooling is properly configured (and if the "pooled" property on the ContextSource is not set to false), pooling should be working as expected.

    You say connections are removed from the pool after 20 seconds, even though you have set timeout to 5 minutes. You also say the number of connections exceed your max (10). This indicates that your pooling is not configured as you think it is. The total number of both in-use and idle connections for a given connection identity cannot exceed the maximum setting (in your case, the connection identity would basically be host + port + principal + credentials).

    First double-check that you don't have duplicate conflicting settings of the pooling properties. Then try setting the timeout to something reasonably small, like two seconds. If that works, try 30 seconds. If they still are released after 20 seconds, you probably have conflicting settings somewhere. Do the same with the max setting. Remember that max overrides init, so if you lower max to 5 and have init still at 10, you automatically lower init to 5 as well.

    Comment

    Working...
    X