Portal 6.2では、LiferayプラットフォームはSASSとCompassを使用してCSSファイルの作成を簡素化し、異なるブラウザタイプのためにコードが重複する際の手作業によるミスを回避しています。
SASSはRubyベースのソリューションで、よく整理された保守性の高いソースを作るのに役立ちます。 さらに、SASSファイルからブラウザ固有のCSSファイル（余分な書式やマクロを含むCSSファイル）を構築します。 これを可能にするために、ポータルにjRubyを搭載し、JVMの中でRubyのコードを実行できるようにしました。これは楽しいかもしれませんが、そうではありません。 本当に。 通常、jRubyがSASSファイルをSASSコンパイラで処理した場合、生成されたファイルはSASSファイルがあるフォルダと同じフォルダ内の.sass-cacheフォルダに格納されます（拡張子は.cssを使っていますが、ファイルにはSASSソースが入っています）。
解決策
jRubyが起動し、可能な限りのCPUを食い尽くすようになるのはいつ頃でしょうか？
SASSファイルをCSSファイルにコンパイルする必要がある場合。
jRubyがSASSファイルをコンパイルするトリガーは何ですか？
DynamicCSSFilterがトリガーとなります。
DynamicCSSFilterがきっかけで、jRubyがSASSファイルを何度も処理するのはなぜですか？
.sass-cacheフォルダのタイムスタンプやパーミッションが乱れているか、.sass-cacheフォルダにキャッシュされたファイルがまったくないかです。
想定されるいくつかの問題点
新しいテーマがデプロイされたが、jRubyがLOTに動作する。 この場合、まず考えるべきは、.sass-cacheフォルダが全くないか、空っぽであることです。
もしそれがないか空であれば、build-cssターゲットが起動されなかったか、ビルド時に失敗した可能性があります。 残念ながら、失敗してもビルドプロセスは停止しないので、失敗したかどうかを検出するのは難しいです。 このような場合、開発者はそれを確認し、再度実行してテーマを再デプロイする必要があります。 (CSSを使用したポートレットも同様です）。
ポータル独自のCSSファイルは、HookやExtプラグインでカスタマイズされています。 この場合、キャッシュされたファイルのタイムスタンプはソースCSSファイルのタイムスタンプと異なるため、DynamicCSSFilterはjRuby経由でSASSコンパイルを開始します。 HookやExtプラグインのCSSファイルに対してbuild-cssが実行され、.sass-cacheフォルダが生成されていなければ、ここでは何もできず、ただjRubyが仕事を終えるのを待つだけです。
これが本番サーバーで発生すると、応答時間が非常に遅くなったり、まったく応答しなくなったりすることがあります！ そのため、本番サーバーにトラフィックを送る前に、イントラネットからページを訪問してテストし、サーバーのCPU使用率を監視して、トラフィックがサーバーに到達した後にjRubyが問題を引き起こすかどうかを確認することが推奨されます。
ポータルは、アプリケーションサーバーのTEMPフォルダーの中にあるliferayというフォルダーに前処理をしたファイルを保存します。 TEMPフォルダをクリーンアップするバックグラウンドジョブがあることがあり、そのためにjRubyが何度も実行されて何度もファイルを処理する可能性があります。 これは厄介な問題なので、次回、jRubyが大量に動作する理由を調べなければならないときに、このことを忘れないようにしてください。
JBoss のようないくつかのアプリケーションサーバーでは、ポータルの .war ファイルが解凍されていない場合、SASS 関連の問題が発生する可能性があります:LPS-52665
MAVENを使用して開発を行うお客様が増えています。 MAVEN SDKでは、build-cssターゲットが断続的に欠落していたため、.sass-cacheが生成されていなかった。 この場合、SDKをアップデートする必要があります。 MAVEN-128を参照してください。