The Course Site Removal job's default configuration is to unpublish sites.
In our seven years of working on Sakai at Western, it's safe to say that this piece has the... 'least optimal' performance. Once, we ran this in our QA environment and got sidetracked; it completed after 12 days of execution.
A big part of this is that it invokes siteService.save(site) has a lot of slow performing hooks (as once might expect, you're saving a whole site afterall!). These hooks include:
- triggering SiteAdvisors
- deleting all pages, tools, properties, etc., associated with the site, then inserting them all back with any modifications
- handling authz group changes
- notifying ContextObservers to do their own work related to the site modification
- triggering EventTrackingService
These are important hooks, but generally, all except the EventTrackingService are not necessary when the job's intention is to simply flip the "published" flag to 0.
So I introduced a sakai.property which allows all those hooked to be bypassed; default is false:
We also have a use case to handle sites that are crosslisted with sections in different terms.
For instance, consider a course that has two sections attached - CompSci101FW18A, and CompSci101FW18B. Those two sections can be in different terms.
If CompSci101FW18A is associated with an Academic Session whose end date is December, and CompSci101B is associated with an Academic Session whose end date is in May, the job currently only considers one of these end dates (the first one that was attached if I'm not mistaken). But we don't want to unpublish this site until both sections' academic sessions' end dates fall before the grace period, so the job needs to consider all the attached sections' Academic Session end dates before it can decide whether it can unpublish the site.
I've introduced a sakai.property for this too that is also off by default: