I have JIRA v5.2.8 (running on Ubuntu 12.04 x64) configured to use our OpenLDAP server for user authentication (not group membership however). Currently we have an Apache2 server as a reverse proxy configured in front of JIRA with basic authentication enabled.
Today, I noticed that the Apache/JIRA combination is doing a search/bind on our LDAP server multiple times per request on every request. This is hampering performance and shouldn't be neccessary.
I know that tools like Apache2 have an LDAP cache to improve performance and I have verified via two different methods that this cache is functioning normally. The http://localhost/ldap-status on the reverse proxy reports the cache is working and other servers (Confluence, Nexus, Jenkins, Fisheye, etc.) do not have this problem of over-taxing our LDAP server.
I also ran a test on JIRA where I logged in directly without going through the reverse proxy and JIRA does seem to cache credentials because after the initial lookup, additional lookups where infrequent.
So the problem must be the combination of basic authentication and JIRA that causes this issue. Again, neither Confluence nor Fisheye exhibit this problem.
Just a guess, but do you use LDAP where permissions are set to authentication only, with local groups. As you can see in this documentation, data caching does not occur for this user directory type.
Maybe - if you have not done so far - you can follow that guide, which might help you to debug. Another solution might be Atlassian's CROWD which reduces the LDAP calls even further (see this quite old, but still valid blog post).
I am curious to know, if this helps you!
I was revising my question when you were typing your answer - thanks for the help. The link you provided is a 404 -- did you mean this: https://confluence.atlassian.com/display/JIRA/Synchronising+Data+from+External+Directories
Our LDAP permission scheme is set to "Read Only, with Local Groups", which, according to the documentation should allow for caching. Not sure where to go next...
Yes I meant the link :
Interstingly my provided link pointed to that URL and I was exeriencing also some unavailability "due to maintenance" as Atlassian says.
Sounds like you're using a connector with periodic synchronisation configured as detailed in https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory - is that right? If so, JIRA will periodically synchronise details by comparing the local cache of users/groups and group membership against openLDAP (typically set at a 60min interval). JIRA will bind to openLDAP when a user attempts to login as it will authenticate the user then, as these details aren't stored within the DB.
Outside of the periodic synchronisations and authentication attempts, JIRA will not attempt to connect to openLDAP.
I haven't seen anyone use the LDAP cache with JIRA before, so I'm guessing you have the openLDAP server sitting behind Apache and JIRA is connecting to OpenLDAP through Apache rather than directly connecting to it - is that right? If it's not going through Apache it wouldn't be able to cache it. That is to say: is the hostname of the User Directory in JIRA using the proxy or the direct connection to OpenLDAP? I realise this is something obvious, just want to make sure!
As for FishEye and Confluence, are they both delegating user management to JIRA, or is Confluence connecting to the OpenLDAP server? FishEye will need to delegate its user management to something else, so that shouldn't be touching OpenLDAP directly at all (it'll sync with JIRA which syncs with OpenLDAP). You can configure Confluence to do this as well, so that may be why you don't see those other applications accessing OpenLDAP.
Also, what kind of numbers are you talking about? It sounds like you must have a very large openLDAP server for there to be performance implications. Depending upon the configuration of the User Directory this can result in syncing more users are necessary. For example, if you sync the root DN of OpenLDAP and there are a significant number of objects in it, it'll increase the sync time. It'd help to get some more info on this. Can you provide the following so we can take a look:
That summary will have IPs in it as well as DNs (no passwords!), so please be aware if this is sensitive information. Other things we could look at:
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot