Uploaded image for project: 'Jira Cloud'
  1. Jira Cloud
  2. JRACLOUD-24162

Avoid replicating entire LDAP/AD identity directories into JIRA local database

    XMLWordPrintable

    Details

    • Feedback Policy:

      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.

      Description

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      Currently, when connecting an external LDAP/AD directory with JIRA, it seems JIRA attempts to make a copy of the users/groups in the identity store into the JIRA database and then periodically checks to make sure they are synchronized. This solution does not scale well with large directories.

      Out-of-the-box JIRA crashed with OutOfMemory error after 15 minutes. After tripling the memory (512min/768max) JIRA got further:

      [atlassian.crowd.directory.DbCachingRemoteDirectoryCache] synchronised [ 24241 ] users in [ 4713513ms ]
      [directory.ldap.cache.UsnChangedCacheRefresher] found [ 57440 ] remote groups in [ 6665358ms ]
      

      ...but then crashed again with another OOM error 3 hours after that last log entry while still processing groups.
      (I was trying to wait to open this issue until I had a completely successful synchronization process to be able to report final timings, but to double the memory again requires adding more physical memory to the machine which will take some time...I thought I would get this issue opened now and report back any additional findings later.)

      Proposed solution: Create users in the local database "only when first needed" rather than up-front. Subsequent synchronization tasks should only be performed on existing users in the database.
      I'm also using the term "only when first needed" to be intentionally vague. This would most likely mean when the user first logs on. But, there could also be other scenarios when a user should be created in the local db as well. (An admin is setting up security and needs to be able to search for and locate specific users, but since the users haven't logged in they don't exist in the db. Users should not be required to logon as the only means to get a user created in the db; instead, there should also be a way to cause a specific user to get created "on demand".)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              24958f8215d1 Feldhacker
              Votes:
              9 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: