This problem is not that easy to reproduce, but let me explain it.

Problem

When a wiki is reached for the first time, a LESS compilation is done, to generate the wiki's skin style.

If too many wikis are accessed for the first time simultaneously, many LESS compilations are done in the same time (even if there is a mutex mechanism that forbid the compilation of the same skin twice).

LESS compilations are quite costly, so having too much leads to an OutOfMemory exception, especially on environments with low memory (like cheap VPS).

We have also experienced this problem by someone who were creating a lot of wikis via a script: SolR was indexing all of them simultaneously so it created a lot of LESS threads in the same time: XWiki crashed. But the use-case was perfectly valid. We should be able to create a lot of wikis quickly.

Proposed solution

After some thinking, Thomas suggested me to add a Semaphore to avoid having more than N LESS compilations at the same time. I've made an experiment on an instance that was crashing everytime and the issue was fixed.

So I propose to implement this in XWiki. The number of simultaneous threads should be configurable so that administrator can select the appropriate number for his environment.

Drawback

But there is a drawback. The LESS compilation is done synchronously with the page load (because of a template which computes a color theme depending on the result of the LESS compilation). So when the LESS compiler waits for the semaphore to be available, the loading of the page is blocked. If it lasts too long, the browser of the user will cancel the loading of the page. XWiki-11263 could help us on this. And we could also see if it is really necessary to compute the color theme on a template.

Anyway, I think that a failed request (the user could still refresh the browser) is better than a crashed wiki.

More over, we have the same problem with a lot of LESS compilations in the same time: it takes long!