We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
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.
Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-24162

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

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? 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".)

            Loading...
            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.
            Uploaded image for project: 'Jira Data Center'
            1. Jira Data Center
            2. JRASERVER-24162

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

              • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

                NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? 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".)

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

                          Created:
                          Updated:
                          Resolved:

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

                              Created:
                              Updated:
                              Resolved: