SiteService.getSites() removes fully cached sites.
GENERAL
TESTING
GENERAL
TESTING
Description
relates to
Activity
Show:
Alexandre Ballesté Crevillén February 14, 2017 at 6:36 AM
It looks pretty fast on qa1-us.nightly.sakaiproject.org. I've not detected any problem searching, updating, etc, so I would say that it passes the test for 11.3 RC01.
Thanks.
Matthew Buckett February 14, 2017 at 6:25 AM
Just a general check of Sakai really. Searching for sites, editing sites.
Alexandre Ballesté Crevillén February 14, 2017 at 6:22 AM
, is there any easy way to test this JIRA for the 11.3 RC01 QA process? I guess that not.
Matthew Buckett January 13, 2017 at 3:15 AM
I think this is worth merging back if we can check it's all working on trunk, however checking on trunk isn't simple.
Matthew Buckett August 24, 2016 at 8:28 AM
My workaround is to just use SiteService.getUserSites() in the calling code, but there may be other places that are throwing good sites out of the cache.
Also we should probably have getSites() recognise when it can use getUserSites()) and call that instead to get the performance boost.
I was recently looking at a performance problem where it looked like some code was loading all of a user's sites from the DB. The code in question wasn't calling
SiteService.getUserSites()but instead was callingSiteService.getSites()and asking for all sites a user has access to. This falls through to the DB which loads all the Site IDs but, then it checks to see if any of these site IDs are cached (lots normally are), but then attempts to load them all anyway. The really bad part of this is that when loading Sites it is just a partial siteBaseSite.isFullyLoaded()returns false and these sites are all put into the cache, replacing sites that were already in the site and already fully loaded.