nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is there a limit to the number of users JIRA can cache from Crowd?

ZachE

I have about 97,000 users in my crowd instance.
I have JIRA set up to sync from crowd.
Only about 90,000 users are getting cached in JIRA's user directory.
Users who are not cached in JIRA's directory do get imported from crowd when they try to log in.
However, they are purged at the next directory sync.
This is problematic because when users are not in JIRA's user cache, they don't show up in user pickers (e.g. they can't be assigned to issues) and their meta data is missing for issues on which they are the assignee/reporter/etc and those issues can't be edited because the user value is invalid.

What is causing the 90k users to get synced? Why aren't the final 7k making it in? At first I thought it was because of mapped groups in the application config in crowd, but I mapped every group and it didn't help. Is there a 90k limit within JIRA on how many users it can cache? Can I adjust that limit somehow?

Accepted answers

ZachE

This whole problem ended up being a bug in our custom crowd connector and not at all a problem with Crowd, JIRA, or any kind of caching.

All comments

ZachE

I see that older versions of JIRA have

.../atlassian-jira/WEB-INF/classes/crowd-ehcache.xml

which is documented here: https://confluence.atlassian.com/display/CROWD/Configuring+Caching+for+an+Application

But the latest version doesn't have that file. Can I simply create it or has its functionality been superceded?

Caspar Krieger

The caching docs for Confluence that you linked to isn't the same thing as the caching that happens for an LDAP directory; those caches are "true caches". I don't know how JIRA has that configured but it probably has something similar; regardless it shouldn't be the cause of your problem.

It could be that there's something (possibly but not certainly a bug) interrupting the sync of those 7,000 users; I'd have a look at the Crowd logs and see if there are any exceptions or messages in the logs warning of users being skipped. If the fix isn't clear from any information there, then I suggest you contact our friendly support team to help you figure out how what's going on (or diagnose a possible bug).

Alternatively, it's possible that you are looking at numbers which mean two different things; you could have 2 directories mapped to the JIRA application in Crowd, and then JIRA sees those 2 applications with the duplicate users (determined by the username) removed.

ZachE

I've got a support ticket open (CWDSUP-10182 fka JSP-216391), just thought it's be good to ask here too. I'm about to submit the crowd log there and also look over it myself. It isn't confusion about the numbers. There is only 1 directory in crowd mapped to JIRA and JIRA only uses Crowd for its User Directory - there's only 1 source of user information, so there's no possibility of duplicates. JIRA is expressly complaining when it imports groups from crowd that some of the users in those groups don't exist (even though they definitely do exist in crowd).

Caspar Krieger

Fair enough. Perhaps someone else has some better ideas

ZachE

We've actually turned up an old test server that we set up with a test crowd instance and the combo doesn't have this problem. All 95k expected users end up in JIRA. So it clearly isn't an inherent limit in JIRA. We're digging in to figure out what the config differences might be.

ZachE

This whole problem ended up being a bug in our custom crowd connector and not at all a problem with Crowd, JIRA, or any kind of caching.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

crowd

crowd-administration

user-management

user-directory