Log inSkip to main contentSkip to sidebar
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.
Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.
LDAP connections over SSL are not pooled, meaning each operation acquires a new TCP connection as well as negotiating SSL. This significantly increases the time taken for operations like synchronisation.
For a default Crowd with no pooling configuration changes, synchronisation is single threaded, so only a single connection is made. (In testing, two connections; it's not clear if that's due to multiple threads or a single connection only being reused so many times.)
In terms of impact, a synchronisation with OpenLDAP that took 1m45 without SSL took as much as 8m15 when SSL was enabled.
Sorin Sbarnea (Citrix)
added a comment - It seems that pooling still doesnt work weel even with 2.8.2 and even without SSL. Take a look at https://support.atlassian.com/servicedesk/customer/portal/16/CWDSUP-10724 (Atlassian only)
to show only connection attempts. If this is working, it will show only the original connection, which will then be reused for subsequent LDAP operations.
joe
added a comment - A useful Wireshark filter for testing this is:
tcp.flags.syn==1 && tcp.flags.ack==0
to show only connection attempts. If this is working, it will show only the original connection, which will then be reused for subsequent LDAP operations.
SetLdapConnectionSettingsListener sets the system properties too late to take effect.
This fix will add the system property to the Tomcat distribution. CWD-4159 is a follow-on issue to remove the redundant UI, or fix it to work.
joe
added a comment - SetLdapConnectionSettingsListener sets the system properties too late to take effect.
This fix will add the system property to the Tomcat distribution. CWD-4159 is a follow-on issue to remove the redundant UI, or fix it to work.
where LdapHostnameVerificationSSLSocketFactory implements Comparator<String>.
That system property is set in Crowd by SetLdapConnectionSettingsListener; other products may need to ensure they take the same steps.
joe
added a comment - In a standalone test, the necessary steps to get pooling were:
System.setProperty("com.sun.jndi.ldap.connect.pool.protocol", "plain ssl");
env.put("com.sun.jndi.ldap.connect.pool", "true");
env.put("java.naming.ldap.factory.socket", "ssl.LdapHostnameVerificationSSLSocketFactory");
where LdapHostnameVerificationSSLSocketFactory implements Comparator<String> .
That system property is set in Crowd by SetLdapConnectionSettingsListener ; other products may need to ensure they take the same steps.
joe
added a comment - For SSL connections, Crowd uses a custom socket factory due to CWD-2690. http://docs.oracle.com/javase/6/docs/technotes/guides/jndi/jndi-ldap.html#pooling states that custom factories must implement Comparator<SocketFactory> to be pooled. http://stackoverflow.com/questions/23898970/pooling-ldap-connections-with-custom-socket-factory points out that it's actually Comparator<String> that's required.
This appears to be an issue with Confluence 5.4.4 as well. We're bringing a new openLDAP server online and noticed that testing the directory from Confluence 5.4.4 with SSL takes quite some time. It doesn't appear to be connection pooling for SSL, making a full test of the LDAP server with SSL take more than 60s. Since the default ajp proxy timeout is 60s, this throws a 500 on the Apache webserver side. Increasing the timeout to more than 60s can help. Searching an LDAP directory shouldn't take very long, under ideal circumstances.
Miles Gentry
added a comment - This appears to be an issue with Confluence 5.4.4 as well. We're bringing a new openLDAP server online and noticed that testing the directory from Confluence 5.4.4 with SSL takes quite some time. It doesn't appear to be connection pooling for SSL, making a full test of the LDAP server with SSL take more than 60s. Since the default ajp proxy timeout is 60s, this throws a 500 on the Apache webserver side. Increasing the timeout to more than 60s can help. Searching an LDAP directory shouldn't take very long, under ideal circumstances.
The logs certainly show that Spring LDAP doesn't think it's enabling pooling:
[ldap.core.support.AbstractContextSource] Not using LDAP pooling
It also looks like the socket factory's creating a new socket each time:
[crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory] Name checking SSLSocketFactory created
Are you able to confirm whether that's accurate? That is, using something like Wireshark, can you see whether a separate TCP connection is made each time? I ask because the interaction between system properties, connection properties and Spring LDAP isn't always clear.
joe
added a comment - The logs certainly show that Spring LDAP doesn't think it's enabling pooling:
[ldap.core.support.AbstractContextSource] Not using LDAP pooling
It also looks like the socket factory's creating a new socket each time:
[crowd.directory.ssl.LdapHostnameVerificationSSLSocketFactory] Name checking SSLSocketFactory created
Are you able to confirm whether that's accurate? That is, using something like Wireshark, can you see whether a separate TCP connection is made each time? I ask because the interaction between system properties, connection properties and Spring LDAP isn't always clear.
In testing, this appears to work when the com.sun.jndi.ldap.connect.pool.protocol system property is set to plain ssl. Crowd should already be setting that on startup (if it's not taking effect that may be a bug). However, other products may not be setting it at all.
joe
added a comment - In testing, this appears to work when the com.sun.jndi.ldap.connect.pool.protocol system property is set to plain ssl . Crowd should already be setting that on startup (if it's not taking effect that may be a bug). However, other products may not be setting it at all.
It seems that pooling still doesnt work weel even with 2.8.2 and even without SSL. Take a look at https://support.atlassian.com/servicedesk/customer/portal/16/CWDSUP-10724 (Atlassian only)