|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [JIRA] (JENKINS-16089) Standard view columns i... [email protected] (JIRA)
- [JIRA] (JENKINS-16089) Standard view colu... [email protected] (JIRA)
- [JIRA] (JENKINS-16089) Standard view colu... [email protected] (JIRA)

I did a little bit more experimentation here, using it to fix the "slow People view" problem that was mentioned on the mailing list:
I now persist the cache (not a true LRU persistent cache, but I think it's a good start without external dependencies); I've switched to requiring cache objects to be Serializable:
https://github.com/justinsb/jenkins/commit/a1c68a1156be0dfa1b6c95578cd0675fa50c8fea
I use the cache to store People, using the same memoize-per-build and incremental update approach:
https://github.com/justinsb/jenkins/commit/a0ae671785ae96e1c85274332d54effe80bc875d
So as to avoid behavioural changes, rather than trying to persist the UserInfo object, instead it stores a reference to the build from which the UserInfo should be loaded. That build still needs to be loaded, but it's only the required builds. If we could persist the UserInfo safely, we could avoid this as well.