[
https://issues.apache.org/jira/browse/JAMES-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3594:
----------------------------------
Description:
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.
was:
# 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...)
# 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".
# 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.
> 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
> Attachments: ldap.png
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
