"Connection reset by peer" not handled?

[andrewb]

Hi all,

thinking about using this library in my project instead of my personal "LDAPManager" class that I've used for years, but I noticed one case which I'm not sure is handled.

Since the LdapTemplate class is a singleton, the initialization of the connection to the ldap server happens only once upon startup. Perfect.

The problem: in a clustered production environment where web apps run uninterrupted for weeks or months at a time, it occasionally happens that the naming server goes down temporarily for whatever reason (network problems, registry server problems, etc). At this point, the original connection is ruined and all calls to ldap return a "CommunicationException: Connection reset by peer". The only way to recover is to restart the web app in order to re-establish the connection.

The question: any plan to handle this elegantly and try to re-establish the connection before throwing the exception? I quickly glanced through the source code and saw that the CommunicationException is simply mapped to a "DataRetrievalFailureException: Unable to communicate with LDAP server", but this unfortunately doesn't resolve the problem of restarting the app, which is a huge pain :-((

Did I miss something or is this right? If so, any chance of implementing the change?

[rasky]

As a matter of fact Spring LDAP does not keep track of any connections. New connections are created for each operation (i.e. method call to the LdapTemplate class). This means that the only possibility to get a CommunicationException would be if the connection is closed abruptly in the middle of an operation.

As opposed to ordinary database connections, LDAP connections are very lightweight with very little overhead - they're basically just a plain socket connection. This means that it is rather inexpensive to create/release LDAP connections.

That aside, there's always the possibility to use LDAP Connection Pooling (configurable in LdapContextSource/DirConextSource). This is purely implemented in the LDAP Service Provider, so it's nothing we worry too much about in Spring LDAP - we just provide the means to turn it on or off. Using connection pooling you will basically reuse the same connection all the time (provided you connect using the same credentials each time), just as you do when using a DB pool. The difference here from keeping track of your connections yourself if that the connection pool keeps track of dead connections, lets you configure the number of concurrent connections etc.

I'm sure the LDAP connection pooling alone would solve your current problems, but of course using Spring LDAP will help you clean up your code as well