LDapTemplate and Connection Pooling

[James Tuan Vu]

Hi all:

I am experiencing a problem where the context.close() is not really releasing the resources until System.gc() is called. I downloaded the LdapTemplate and unless I added the System.close() in the LdapTemplate.closeContext() I cannot get a new connection!

help,
JT

[rasky]

I'm unsure whether you want to use connection pooling or not. If you don't want to use connection pooling, set the 'pooled' property of your ContextSource to false, which will cause the connections to be immediately closed after each operation.

If you do want to use connection pooling, the connections will in deed not be released until the pool times out (default is infinite timeout; you control this with system properties).

[James Tuan Vu]

I do want to use connection pool, but I do not understand your comments about how the connection pool be released has to do with timeout.

first of all, I just need upon close() to "release" the connection back to the pool so other request can use it. Currently it is not doing that till System.gc() is called.

secondly, doesn't timeout have to do with the idle connections in the pool? If so then this really should not be affecting when the connection be released back to the pool after context.close() is called, correct?

JT

[rasky]

Sorry, I misunderstood your question; I thought you were talking about actually closing the connections, not returning them to the pool.

Anyway, calling DirContext.close() (as is done in all operations in LdapTemplate) should indeed return the connection to the pool, but only if all references to that particular connection have been correctly closed. Some operations create a copy of the original DirContext with a reference to the original connection, but normally that shouldn't happen when using LdapTemplate if it is correctly configured.

We did have a problem in DefaultDirObjectFactory in an earlier version of LdapTemplate, where one reference was not closed, but that was fixed in version 1.0.1.

How are you observing that the connection is not returned to the pool? I might need to see some configuration and code to be able to help you.

[James Tuan Vu]

Ouch... I am using 1.0. Let me try with 1.0.1

thanks,
JT

[James Tuan Vu]

Hi again,

I tried 1.0.2 but it does not seem to return to the pool either. This is how I debug if it returns to the pool or not.

1) I set the pool max size to 1, com.sun.jndi.ldap.connect.pool.maxsize=1
2) i set the debug to fine, com.sun.jndi.ldap.connect.pool.debug=fine
3) I also use AOP to see the logging for net.sf.ldaptemplate.support.LdapContextSource
4) I should be seeing the
Create com.sun.jndi.ldap.LdapClient@...
Use com.sun.jndi.ldap.LdapClient@...

and upon close(), I should see
Release com.sun.jndi.ldap.LdapClient@...

but the problem is I do not see the Release and furthermore, the application got hung on the net.sf.ldaptemplate.support.LdapContextSource getReadOnlyContext

Again, I added the System.gc(), everything seems to be OK. I think there might be another leak somewhere but not sure. However I am sure that it is not returning to the pool upon close() context.

thanks for your help,
JT

[rasky]

Right, it does indeed seem that there is a reference somewhere that is not properly closed.

I'll probably need to see some code and configuration in order to track down the problem.

[James Tuan Vu]

I finally got it to work. I found that in order to the LdapTemplate to work properly in the pooling, one must use the DefaultDirObjectFactory via injecting to the variable dirObjectFactory for the LdapContextSource.

Once I do that things starts to fall into place. My question is if this is so, then the dirObjectFactory should have defaulted to the DefaultDirObjectFactory, otherwise make it a required field. Why would one makes it optional and then it does not work properly if it is not set.

thanks for your hint,
JT

[rasky]

Right, that figures. The reason why it's not required (or defaulted) is that it is only required when you use the methods that take ContextMapper as an argument.

Nevertheless it would make sense to make the DefaultDirObjectFactory the default; after all it is only in very rare special cases you would like to use a different DirObjectFactory and there's really no additional performance cost if it's not used. At the very least, it should be very clearly documented.

Thanks for your input.