Announcement Announcement Module
Collapse
No announcement yet.
timeout connection pool IGNORED Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • timeout connection pool IGNORED

    Hi,

    I use spring framework (Spring LDAP v1.0.2) to access LDAP directory. I develop a classic DAO (see http://static.springframework.org/sp...1.1/reference/) with LdapTemplate and ContextMapper...

    Spring configuration : ...
    Code:
    <bean id="contextSource" class="org.springframework.ldap.support.LdapContextSource">
    	<property name="url" value="${ldap.auth.url}" />
    	<property name="base" value="${ldap.auth.basedn}" />
    	<property name="userName" value="${ldap.auth.manager.dn}" />
    	<property name="password" value="${ldap.auth.manager.password}" />
    	<property name="pooled" value="true" />		
    </bean>
    	
    <bean id="ldapTemplate" class="org.springframework.ldap.LdapTemplate">
    	<constructor-arg ref="contextSource" />
    </bean>
    Ldap use exemple...
    Code:
    public void modifyCompte(UtilisateurLdap userLdap) throws LdapDaoServiceException{
    	try{
    		DirContextAdapter context = (DirContextAdapter)ldapTemplate.lookup(userLdap.getDn());
    		
    		mapUtilisateurToContext(userLdap, context);
    			
    		ldapTemplate.modifyAttributes(userLdap.getDn(), context.getModificationItems());
    	} catch (AttributesIntegrityViolationException  e) {
    		throw new LdapDaoServiceException("Attribut manquant ou invalid => " + e.getMessage(), e);
    	} catch (UncategorizedLdapException ule) {
    		throw new LdapDaoServiceException("Erreur ldap => " + ule.getMessage(), ule);
    	}
    }
    This application works.... but in my company, the firewall and openLdap are configured to close all idle connexion after ONE hour !! Therefore LdapTemplate don't know about this and after 1 hour an exception append :
    Code:
    Operation failed; nested exception is javax.naming.ServiceUnavailableException: osiris.santeclair.lan:389; socket closed
    org.springframework.ldap.UncategorizedLdapException: Operation failed; nested exception is javax.naming.ServiceUnavailableException: osiris.mycompany.lan:389; socket closed
    javax.naming.ServiceUnavailableException: osiris.mycompany.lan:389; socket closed; remaining name ''
    So ... after that i try many thing:
    1:
    Code:
    <bean id="contextSource" class="org.springframework.ldap.support.LdapContextSource">
    	...
    	<property name="pooled" value="true" />		
    	<property name="baseEnvironmentProperties">
    		<map>
    			<entry key="com.sun.jndi.ldap.connect.pool.timeout" value="300000"/> <!-- 5 minutes -->
    			<entry key="com.sun.jndi.ldap.connect.pool.debug" value="fine"/>
    		</map>
    	</property>		
    </bean>
    2: java parameter
    Code:
    java -Dcom.sun.jndi.ldap.connect.pool.timeout=300000 YourProgram
    But parameter com.sun.jndi.ldap.connect.pool.timeout seems to be always ignored....

    I don't want use program without pool (<property name="pooled" value="false" />) and close every context after use (do context.close() at the end of in my previous exemple), it isn't a good way !


    CAN ANYONE HELP ???

  • #2
    I read this :
    The LDAP provider keeps track of whether a connection is being used through indications from the application. It assumes that an application that is maintaining an open context handle is using the connection. Therefore, in order for the LDAP provider to properly manage the pooled connections, the application must be diligent about invoking Context.close() on contexts that it no longer needs.

    Bad connections are automatically detected and removed from the pool. The probability of a context ending up with a bad connection is the same regardless of whether connection pooling is used.
    So I should invoking "context.close()" .... so funny but i only use an explicit context to modify or create user.

    What i should do with search, update user group, and delete (unbind) user !!? if i use [ DirContextAdapter context = (DirContextAdapter)ldapTemplate.lookup(AdminManage rDn); ] or [ DirContextAdapter context = new DirContextAdapter(AdminManagerDn);], i cannot be sure that the last connexion use !!!
    Code:
    public void deleteCompte(Name userDN) 
    	ldapTemplate.unbind(userDN);
    	DirContextAdapter context = new DirContextAdapter(AdminManagerDn);
    	context.close();
    In this other case, it is crazy !! Because if search return more than one result, the connexion became idle...
    Code:
    List users = ldapTemplate.search("", filtreRecherche, new ContextMapper() {
    	public Object mapFromContext(Object ctx) {
    		DirContextAdapter context = (DirContextAdapter)ctx;
    
    		UtilisateurLdap user = new UtilisateurLdap();
    		user.setDn(context.getDn());
    	user.setUserId(context.getStringAttribute(LdapNomAttribut.LDAP_USER_ID));
    
    		context.close(); //for all result !!
    
    		return user;
    	}
    });

    Any idea ??

    Comment


    • #3
      You mention that you use Spring LDAP 1.0.2. There is no such version, but the old Sourceforge project LdapTemplate did release a 1.0.2. Is that what you're using?

      I remember there was a pooling issue in that library if you hadn't specifically set DefaultDirObjectFactory on your LdapContextSource. See more in this thread.

      You should upgrade to Spring LDAP if you're using the old LdapTemplate. More info on that here.

      Comment


      • #4
        Sorry, i use Spring Ldap 1.1.2

        Comment


        • #5
          First of all, setting the pooling properties on the ContextSource using baseEnvironmentProperties will not work. The reason is that they are system properties, not environment properties, as documented in the JNDI tutorial. Either you can give the properties to the Java runtime or set them in your code using System.setProperty. Your second example, where you use -D, should work. Try setting a shorter timeout and look at the tracing information. Note that the Context must be idle for the specific time before its underlying connection is closed and released from the pool. It is considered idle after Context.close() has been called.

          The pooling is performed by the LDAP provider and is completely external to Spring LDAP. The benefit of using LdapTemplate is that it guarantees that the Context is properly closed and returned to the pool.

          Comment


          • #6
            thanx, i will test it monday...

            Comment


            • #7
              Also note that calling close() on a DirContextAdapter instance won't do anything at all. The DirContextAdapter is for manipulating Attributes only, and it doesn't hold any Connection to the LDAP server.

              Comment


              • #8
                I test it this morning...

                Right, i test one more time the '-D' argument and it work. But as you say usla it a system property, so every program will use it. That for me a problem because each program of my company use Ldap in a different way (with/without pool ...).

                Is there an other solution to close automatically a connection ??? or what can use to close manually one or all connection in the pool ??

                "after Context.close() has been called." What is the Context Object or which Context Object can i use with LdapTemplate to do it ??


                Good week everybody ...

                Comment


                • #9
                  There's really nothing we can do in Spring LDAP about the LDAP connection pooling in the LDAP Service Provider. We do close all contexts properly, so if pooling is properly configured they will be released by the pool. If the pool is configured to hold on to the connections, well - there's really nothing we can do about it.

                  An alternative to the built-in pooling would be to have a look at this thread. The proposed pooling library addresses a couple of problems with the built-in pooling support, such as the system-wide configuration and 'dead' connections in the pool. I haven't been using it all that much myself, but it looks good and it is likely to be included in a later release of Spring LDAP.

                  Comment

                  Working...
                  X