Setup

• JIRA & Crowd on one machine.
• Internal directory with 1 user in PostgreSQL on same machine.
• Active Directory 2003 in a VM on a different machine. This is a slow server.
• Just over 2000 users in AD instance.
• SSL not enabled.

Reloading the User Cache

• Before: 55-60 seconds.
• After: 2-3 seconds.

Your results will vary depending on your configuration, the size of your directory instance, and on how fast it is.

And will we see another 1.4 point release for this or am I going to have to risk even more new features on our production systems in order to get the bug fixes?

I have re-opened this because, JIRA's cache will expire on a periodic basis which may cause serious performance hits until the cache has been rebuilt. I think we still have some investigation to do with regard to smarter cache updating. Unfortunately, I cannot provide an estimated fix version for this at this time. I'm hoping to discuss this with the dev team next week to see where we can fit this in the road map or, perhaps, if I should raise a new, more specific issue for this.

I know you experienced some issues with JIRA integration and Crowd's nested-groups capability in the 1.4 release, which we were able to resolve. I completely understand your hesitancy to upgrade to a new major release as a result of this. Please know the team is working hard to provide a smooth 1.5 release.

Cheers,
Donna

Since we have used the crowd-ehcache.xml file as was advised by the upgrade guide; we are facing slow updates of jira and confluence.
If we add a user or group to crowd, it now takes like 10 to 30 minutes before I actually see the user or group.
Very annoying if you want to add the group to a permission scheme directly.

Our performance is great, we have over 4000 users. We upgraded recently.

We forgot to put the new crowd client libraries in Confluence and Jira and it was still slow, but once we did that it was much better.

I don't know why our experience was different.

I seriously hope you are going to change something in the next release.

We're working on this as the top priority for Crowd 1.6. We're still in the investigation phase, so I can't tell you exactly what form the solution will take. But one will come

I know the design of JIRA necessitates having a copy of all the user data all the time, so I'm not sure what direction you'll need to go. My (unsolicited) suggestion would be to somehow anticipate a cache expiry and have the client update the cache in the background, before the cache actually expires.

g.

Crowd 1.6 is now available at the Crowd Download Centre. While we've not made major changes to the client libraries, we have implemented a caching for Active Directory and ApacheDS on the server, which should solve most people's JIRA performance issues.

I'm going to close this issue. If, after upgrading to 1.6, you're still experiencing problems, please either contact support or open a JIRA ticket specific to your directory or configuration.

Regards,
Dave.
Crowd Product Manager.

ps: Merry Christmas

is the event-based caching mechanism planned or investigated also for OpenLDAP? I can see from the following quote that persistent searches are somehow supported.

For those who care, OpenLDAP introduced persistent search in its implementation of pull or sync replication (syncrepl) in OpenLDAP 2.2 a couple of years ago. We've considered surfacing it for enterprise use when customers have been curious but none have really pressed for the capability.

Cheers,
Aggelos

We're planning on investigating it for OpenLDAP, but we don't have a specific timeframe. Please feel free to create an issue for it.

Unfortunately, sync replication and persistent search are different mechanisms, and it appears that OpenLDAP doesn't expose the Persistent Search control. Although, since there are so many ways to configure OpenLDAP, it's possible that we simply haven't managed to set one of our test instances up to correctly expose it.

Cheers,
Dave.