Announcement Announcement Module
Collapse
No announcement yet.
SpringLdap PoolingContextSource issue - URGENT Please HELP Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SpringLdap PoolingContextSource issue - URGENT Please HELP

    Please help me!! I have been struggling and trying trying to get rid of CommunicationExecption every time.. not sure.. If I am doing some stupid.. I am using spring-ldap-1.3.1.RELEASE.. We've decided to use spring ldap.. after our initial POC went well........ !!

    First time I am calling my service.. its working very good with below configuration and pooled the DirContext which is created by DirContextPoolableObjectFactory
    If I trigger same call for ldap search in few seconds... Its not creating new one.. using old one.. that also excellent.. here are the questions..

    Q1) If I trigger same ldap search after a minute... testOnBorrow=false its welcoming with below error... with testOnBorrow=true, its giving error.. and working well.... why in a minute giving error.. how long will it be active.... with out error.. how to configure that for active object/connection for longer time... if we can ?

    Q2) testOnBorrow doing some attempt to LDAP when the object/connection to ldap is not valid.....well, our LDAP admin says that its doing very bad search attempt...
    Can we customise this search attempt using custom search criteria... instead of leaving it to DefaultDirContextValidator

    Debug Log
    ----------
    DEBUG, ldap.pool.factory.DirContextPoolableObjectFactory, (), (Creating a new READ_ONLY DirContext)
    DEBUG, ldap.pool.factory.DirContextPoolableObjectFactory, (), (Created new READ_ONLY DirContext='javax.naming.ldap.InitialLdapContext@1 eeef8c')

    Error Log
    ---------
    org.springframework.ldap.CommunicationException: connection closed; nested exception is javax.naming.Communica
    tionException: connection closed [Root exception is java.io.IOException: connection closed]; remaining name ''

    at org.springframework.ldap.support.LdapUtils.convert LdapException(LdapUtils.java:100)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:319)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:259)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:606)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:524)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:473)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:493)
    at org.springframework.ldap.core.LdapTemplate.search( LdapTemplate.java:513)

    Below is my configuration
    ------------------------
    <bean id="ldapTemplate" class="org.springframework.ldap.core.LdapTemplate" >
    <property name="contextSource" ref="poolingContextSource" />
    </bean>

    <bean id="poolingContextSource" class="org.springframework.ldap.pool.factory.Pooli ngContextSource">
    <property name="contextSource" ref="contextSourceTarget" />
    <property name="dirContextValidator" ref="dirContextValidator" />
    <property name="testOnBorrow" value="false" />
    <property name="testWhileIdle" value="false" />
    <property name="minEvictableIdleTimeMillis" value="1000"/>
    </bean>

    <bean id="dirContextValidator" class="org.springframework.ldap.pool.validation.De faultDirContextValidator">
    <property name="filter" value="tiaacustomernum=234567"/>
    </bean>

    <bean id="contextSourceTarget" class="org.springframework.ldap.core.support.LdapC ontextSource">
    <property name="url" value="ldap://10.199.27.160:2389" />
    <property name="base" value="dc=tiaa-cref,dc=org" />
    <property name="userDn" value="uid=smuser,ou=people,dc=tiaa-cref,dc=org" />
    <property name="password" value="abcd1234" />
    <property name="pooled" value="false"/>
    <property name="baseEnvironmentProperties">
    <map>
    <entry key="com.sun.jndi.ldap.connect.timeout" value="1000" /> <!-- 1 sec -->
    <entry key="com.sun.jndi.ldap.connect.pool.debug" value="true"/>
    </map>
    </property>
    </bean>

  • #2
    For your question 2 "Can we customise this search attempt using custom search criteria... instead of leaving it to DefaultDirContextValidator": Yes, you can pass in the custom search filter, base etc as properties. You can also implement the DirContextValidator interface and provide your custom search implementation.

    This was long time ago, but the LDAP server I was hitting had a configuration to close the connection on the server end after certain amount of time. So testOnBorrow would simply discard that connection and try to get a new one. Not sure if that is what is happening with you.

    If you keep running into problems with PoolingContextSource, I would suggest trying with out the pooing. It might be that your application might not need the "extra speed" that pooling would give.

    Comment


    • #3
      bvar-thanks for the reply.. it shed enuf light for me...

      1) without pooling its working fine.. (lol.. any app needs "extra speed" - we are in "moving in no time era")
      2) implemented custom DirContextValidator for testOnBorrow validation, which is fairly simple.. changed search scope and filter
      3) as you said, it may have limitation to close the connection in my case.. if it might too short from ldap server side.. it might loose da connection, even tho object is still in pool thats where testonborrow in place, but I still need to check with ldap admin about this.. and update soon here..
      4) Appreciated, If somebody gives following config properties.. for the 500 calls an hour in average for the productionization..
      maxTotal, maxIdle, minIdle, maxWait, whenExhaustedAction, timeBetweenEvictionRunsMillis,
      numTestsPerEvictionRun, minEvictableIdleTimeMillis
      I know, we have default values @ http://static.springsource.org/sprin...l/pooling.html
      probably we may have limitations no.of connections from server side as well - to keep note of it...(but we can adjust this)

      Comment


      • #4
        LDAP Pooling required

        I'm experiencing a similar problem. I set up a pool because I wan't the best possible response time. The service running at the moment is not taking much load but will pick up soon. I would prefer if the socket connections stay alive for a minimum amount of time, or there wouldn't be a need for pooling.

        If I follow the suggestion from before, where pooling is removed, I will incur socket setup/teardown costs. What's the proper solution to keep a pool of LDAP connections working as is done with DB connections say? Is it not the same principle that applies?

        Comment

        Working...
        X