Details
-
Bug
-
Resolution: Fixed
-
High
-
4.4.1
-
None
Description
Summary
Bitbucket Server using ldaps makes clone perform slower than using ldap
That happens because Embedded Crowd does not pool LDAP connections. Reference:
Steps to Reproduce
- Install BBS
- Link it to an LDAP server using ldaps
- Link it to an LDAP server using ldap
It is much faster using ldap.
Expected Results
There shouldn't be such difference.
Actual Results
This is a typical authentication over ldaps on atlassian-bitbucket-profile.log file. Notice it takes 8 seconds:
2016-03-21 00:02:38,309 | http-nio-7990-exec-7 | *5PJ9S7x2x147120x0 | XXXXX | - [7346ms] - "GET /scm/beg/beg_test.git/info/refs HTTP/1.1" [7048ms] - Authentication org.springframework.security.authentication.AuthenticationProvider.authenticate(Authentication) [4ms] - attemptAuthentication - com.atlassian.bitbucket.server.bitbucket-crowd-sso:crowdSsoAuthHandler [2ms] - CaptchaTicket com.atlassian.stash.internal.user.CaptchaService.checkCaptcha(String,CaptchaResponse) [7039ms] - attemptAuthentication - com.atlassian.bitbucket.server.bitbucket-authentication:crowdHttpAuthHandler [7039ms] - ApplicationUser com.atlassian.stash.internal.user.CaptchaService.authenticateWithCaptcha(CaptchaTicket,UncheckedOperation) [7039ms] - ApplicationUser com.atlassian.bitbucket.user.UserService.authenticate(String,String) [4ms] - InternalNormalUser com.atlassian.stash.internal.user.StashUserDao.loadUser(User) [4ms] - Page com.atlassian.bitbucket.user.UserService.findGroupsByUser(String,PageRequest) [3ms] - InternalRepository com.atlassian.stash.internal.repository.RepositoryDao.getBySlug(String,String) [5ms] - Page com.atlassian.bitbucket.user.UserService.findGroupsByUser(String,PageRequest) [4ms] - boolean com.atlassian.bitbucket.scm.ScmRequestCheckService.checkActionAllowed(ScmRequest) [1ms] - boolean com.atlassian.bitbucket.license.LicenseService.canLogin(Principal) [6ms] - Ticket com.atlassian.bitbucket.throttle.ThrottleService.acquireTicket(String) [268ms] - /opt/stash/installs/git/bin/git http-backend
Thread dumps taken during the same period are stuck in the SSL handshake:
"http-nio-7990-exec-8" #266 daemon prio=5 os_prio=0 tid=0x00007f6be0074800 nid=0x5cd5 runnable [0x00007f6bcd2a5000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:170) at java.net.SocketInputStream.read(SocketInputStream.java:141) at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) at sun.security.ssl.InputRecord.read(InputRecord.java:503) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) - locked <0x00000000eb1a5710> (a java.lang.Object) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) - locked <0x00000000eb1a56d0> (a java.lang.Object) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387) at com.sun.jndi.ldap.Connection.createSocket(Connection.java:376) at com.sun.jndi.ldap.Connection.<init>(Connection.java:203) at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137) at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at javax.naming.InitialContext.init(InitialContext.java:244) at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) at org.springframework.ldap.core.support.LdapContextSource.getDirContextInstance(LdapContextSource.java:42) at org.springframework.ldap.core.support.AbstractContextSource.createContext(AbstractContextSource.java:344) at org.springframework.ldap.core.support.AbstractContextSource.doGetContext(AbstractContextSource.java:140) at org.springframework.ldap.core.support.AbstractContextSource.getReadWriteContext(AbstractContextSource.java:175) at org.springframework.ldap.transaction.compensating.manager.TransactionAwareContextSourceProxy.getReadWriteContext(TransactionAwareContextSourceProxy.java:88) at org.springframework.ldap.transaction.compensating.manager.TransactionAwareContextSourceProxy.getReadOnlyContext(TransactionAwareContextSourceProxy.java:61) at org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:802) at org.springframework.ldap.core.LdapTemplate.lookup(LdapTemplate.java:935) at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$9.timedCall(SpringLdapTemplateWrapper.java:288) at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper$TimedCallable.call(SpringLdapTemplateWrapper.java:126) at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.invokeWithContextClassLoader(SpringLdapTemplateWrapper.java:89) at com.atlassian.crowd.directory.ldap.SpringLdapTemplateWrapper.lookup(SpringLdapTemplateWrapper.java:284) at com.atlassian.crowd.directory.RFC4519Directory$3.lookup(RFC4519Directory.java:584)
Workaround
Add the following parameters to the JVM_SUPPORT_RECOMMENDED_ARGS parameter in <Bitbucket_Install/bin/setenv.sh and restart your instance:
JVM_SUPPORT_RECOMMENDED_ARGS="-Dcom.sun.jndi.ldap.connect.pool.protocol='plain ssl' -Dcom.sun.jndi.ldap.connect.pool.authentication='none simple DIGEST-MD5'"
In our testing we found it to be less than 1 second with ldap.
Attachments
Issue Links
- is blocked by
-
BSERV-9071 JAVA_OPTS for Bitbucket Server are incorrectly applied to bundled Elasticsearch
- Closed
- is related to
-
JRACLOUD-41025 Pool SSL LDAP connections
- Closed
-
JRASERVER-41025 Pool SSL LDAP connections
- Closed
- relates to
-
CWD-4159 LDAP pool configuration doesn't take effect
- Closed
-
FE-6467 Verify we enable SSL connection pooling for LDAP servers
- Closed
-
CWD-4070 Pool SSL LDAP connections
- Closed
-
KRAK-260 Loading...
- Testing discovered
-
BSERV-9071 JAVA_OPTS for Bitbucket Server are incorrectly applied to bundled Elasticsearch
- Closed
- mentioned in
-
Page Loading...