My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2260: LDAP horrendous login time due to recursive lookup
9 people starred this issue and may be notified of changes. Back to list
Status:  Released
Owner:  ----
Closed:  Mar 2015


Sign in to add a comment
 
Reported by jamestn...@gmail.com, Nov 15, 2013
************************************************************
***** NOTE: THIS BUG TRACKER IS FOR GERRIT CODE REVIEW *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, INTERNAL *****
***** ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.    *****
***** THOSE ISSUE BELONG IN DIFFERENT ISSUE TRACKERS!  *****
************************************************************

Affected Version: 2.4.1 - appears code still present in master.

What steps will reproduce the problem?
1. setup ladp server (AD) in a different region (high latency)
2. create an LDAP user with a large number of LDAP groups (memberOf)
3. login to Gerrit
<wait>
4. logout of Gerrit
5. login to Gerrit

What is the expected output? What do you see instead?

The subsequent login should be quick as all information (groups) should be cached.

What actually happens in the subsequent login takes the same time as the first login (20+ seconds).

Please provide any additional information below.

The reason appears to be that the LDAP realm tries to be helpful
 https://code.google.com/p/gerrit/source/browse/src/main/java/com/google/gerrit/server/ldap/LdapRealm.java?r=60f537ab1944a3c2340c33f882420256501c1410#279

THis tries to pre-populate the cache by fetching all the information about the groups that the user being authenticated is a member of.
However this has several issues
1) it ignores the case that the group info may already be cached and performs another lookup
2) it assumes (by doing this) that most of the groups the user is a member of will actually be used in gerrit.

For many enterprise installations these assumptions are not good, and a simple user will be a member of 100+ groups (with an RTT of 150ms to the LDAP server this in request response times adds up to be not insignificant.)

This eager cache should either be removed, made asynchronous to the login attempt, made configurable, or not lookup groups already in the cache.

Feb 3, 2015
Project Member #1 ziv...@gmail.com
This should fix at least a part of the issue:

https://gerrit-review.googlesource.com/63811

I did compare the first and the follow-up logins of the same user and found out that in a follow-up login significantly less data gets fetched from the LDAP. From what I have seen the group membership info is cached.
Labels: FixedIn-2.11
Feb 10, 2015
Project Member #2 ziv...@gmail.com
Two additional changes should fix the rest of the issue:

https://gerrit-review.googlesource.com/64289
https://gerrit-review.googlesource.com/64400

Mar 16, 2015
Project Member #3 ziv...@gmail.com
(No comment was entered for this change.)
Status: Submitted
Mar 19, 2015
Project Member #4 david.pu...@sonymobile.com
(No comment was entered for this change.)
Labels: -FixedIn-2.11 FixedIn-2.10.1
Mar 19, 2015
Project Member #5 david.pu...@sonymobile.com
(No comment was entered for this change.)
Status: Released
Sign in to add a comment

Powered by Google Project Hosting