In Portal 6.2, the Liferay platform uses SASS and Compass to simplify CSS file creations, and to avoid manual mistakes during code duplication for distinct browser types.
SASS is a Ruby based solution that helps you to make well-organized and maintainable source. Furthermore it builds browser specific CSS files from the SASS files (CSS files with some extra formatting and macros). To enable this, we included jRuby in the portal, so it can run Ruby code inside the JVM, which could be fun, but it's not. Really. Normally, if jRuby processed the SASS files with the SASS compiler, the generated files will be stored in .sass-cache folders in the same folder where the SASS files are (we use the .css extensions, but the files contain SASS source).
When would jRuby kick in and start to eat up all possible CPUs?
When it has to compile SASS files into CSS files.
What triggers jRuby to compile SASS files?
DynamicCSSFilter triggers it.
Why does DynamicCSSFilter trigger jRuby to process SASS files over and over again?
Something is messed up in the .sass-cache folder, either with the timestamps or the permissions, or there are no cached files in .sass-cache folder at all.
Some Possible Issues
A new theme is deployed but jRuby runs a LOT. In this case the first thing that we should think about is that there's no .sass-cache folder at all, or it's empty.
If it's not there or empty, then it's possible that the build-css target was not invoked or have failed during build time. Unfortunately it's hard to detect if it failed, as the build process does not stop if it failed. In this situation, the developer should check it, and run it again and redeploy the theme. (Same applies to portlets with CSS).
Portal's own CSS files were customized with Hook or Ext plugin. In this case the cached files' timestamps will differ from the source CSS files' timestamps, hence DynamicCSSFilter will trigger SASS compilation via jRuby. Unless build-css ran before on the Hook or the Ext plugin's CSS files and generated a .sass-cache folder, we cannot do much here, just wait for jRuby to finish it's job.
If this happens on a production server, it can cause very slow response times or no response at all! So before traffic is routed to a production server, it is recommended to test the pages by visiting them from the intranet and monitoring CPU usage of the server, to see whether jRuby will cause issues once traffic hits the server.
The portal stores preprocessed files in the Application Server's TEMP folder in a folder called liferay. Sometimes there are background jobs that clean up the TEMP folder, which could cause jRuby to run again and again to process the files over and over again. This is a nasty issue, so do not forget about it, when next time you have to find out why jRuby runs so much.
On some Application Servers like JBoss, it can cause SASS related issues if the .war file of the portal is not exploded (extracted):LPS-52665
More and more customers are using MAVEN for their developments. In MAVEN SDK the build-css target was missing intermitently, hence the .sass-cache was not generated. If this is the case, the SDK should be updated, see MAVEN-128.