[jira] [Closed] (JAMES-3594) Each authentication against the LDAP backend starts a thread and opens a connection

["Benoit Tellier (Jira)" <se...@james.apache.org>]

     [ https://issues.apache.org/jira/browse/JAMES-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Tellier closed JAMES-3594.
---------------------------------
    Fix Version/s: 3.7.0
       Resolution: Fixed

UnboundId had been running smoothly on our pre-production for over a month now.

> Each authentication against the LDAP backend starts a thread and opens a connection
> -----------------------------------------------------------------------------------
>
>                 Key: JAMES-3594
>                 URL: https://issues.apache.org/jira/browse/JAMES-3594
>             Project: James Server
>          Issue Type: Bug
>          Components: ldap
>    Affects Versions: 3.6.0
>            Reporter: Benoit Tellier
>            Priority: Major
>              Labels: perf
>             Fix For: 3.7.0
>
>         Attachments: ldap.png
>
>          Time Spent: 3h
>  Remaining Estimate: 0h
>
> h3. What
> While doing some profiling on IMAP, I discovered that we start a thread and open a connection for each authentication performed by IMAP, JMAP, SMTP users.
> See attached picture.
> Here is the incriminated code:
> {code:java}
>     @Override
>     public boolean verifyPassword(String password) {
>         boolean result = false;
>         LdapContext ldapContext = null;
>         try {
>             ldapContext = this.ldapContext.newInstance(null);
>             ldapContext.addToEnvironment(Context.SECURITY_AUTHENTICATION,
>                     LdapConstants.SECURITY_AUTHENTICATION_SIMPLE);
>             ldapContext.addToEnvironment(Context.SECURITY_PRINCIPAL, userDN);
>             ldapContext.addToEnvironment(Context.SECURITY_CREDENTIALS, password);
>             ldapContext.reconnect(null);
>             result = true;
>         } catch (NamingException exception) {
>             // no-op
>         } finally {
>             if (null != ldapContext) {
>                 try {
>                     ldapContext.close();
>                 } catch (NamingException ex) {
>                     // no-op
>                 }
>             }
>         }
>         return result;
>     }
> {code}
> Needless to say, underload opening so much connections, and starting so much threads is of course detrimental. (I wonder if it could have been the root cause of some LDAP incidents...)
> h3. Why?
> Because we use JNDI to read the LDAP, because the standard is to try to authenticate as the user against the LDAP, and because doing so requires a new connection.
> Directory-api is only used to sanitize filter, but appart from that data-ldap fully relies on "JNDI".
> h3. How to fix it?
> Apparently there is little way around with JNDI. I tried to use subcontexts (failed), removing the 'Reconnect' (fails).
> I believe the best way to fix this is to completly drop the JNDI usage.
> Having (quickly) discussed the topic with [~rouazana] (James committer and LDAP expert) we could choose "directory-api" (apache folks), but the UnboundID LDAP SDK could be a good candidate for this too.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org