-
Suggestion
-
Resolution: Fixed
-
None
-
None
Currently we cache calls made in atlassian-user and os-user to improve the user manager layer of Atlassian products.
It would make sense to push the caching responsibility down the stack (to the Crowd client layer) so that:
- caching code doens't need to be duplicated
- all applications using the Crowd client can take advantage of the "free" caching
- it allows us to develop an event driven cache in the future to further improve performance of all applications using the Crowd client.
- is related to
-
CWD-763 Crowd client libraries for JIRA using AD with SSL enabled are unacceptably slow.
-
- Closed
-
-
- Closed
- relates to
-
- Closed
- was cloned as
-
- Closed
[CWD-614] Implement caching on Crowd client layer
David O'Flynn [Atlassian]
added a comment - Splitting out Active Directory/SSL/JIRA work from overarching issue.
David O'Flynn [Atlassian]
added a comment - Splitting out Active Directory/SSL/JIRA work from overarching issue. Every time a Crowd client needs to write the SSO token to a cookie, it makes a call to the Crowd Server to look up the "domain" property.
This is wasteful. It should at the very least be cached (in the future, consider pushing this property to clients when it is changed on the server).
Two parts:
1- Rationalise existing cache(s) in client layer. Ensure there's only one.
2- Optimize cache updates - make sure that when a client updates user/group details, these are passed sensibly to the server and the local cache refresh is smart.
3- Remove need for complete cache timeout, by geting updates-only to the client applications. May be polling or pushing. Reducing cache staleness is also a goal.
If we decide to push data from the Crowd server to the client application, some of the techniques mentioned here may be useful.
David O'Flynn [Atlassian]
added a comment - - edited Two parts:
1- Rationalise existing cache(s) in client layer. Ensure there's only one.
2- Optimize cache updates - make sure that when a client updates user/group details, these are passed sensibly to the server and the local cache refresh is smart.
3- Remove need for complete cache timeout, by geting updates-only to the client applications. May be polling or pushing. Reducing cache staleness is also a goal.
If we decide to push data from the Crowd server to the client application, some of the techniques mentioned here may be useful. 
Rationalisation of caches is complete. Other potential pieces of work are split into separate issues - see those linked issues.