ファーストホップとセカンドホップを試してみる。なるほど、JCRは、Reposityがそのリポジトリの情報で、ReposityにCredentialsを渡すことで、そのリポジトリにアクセスするためのSessionを得られるのか。っで、そのセッションを使って、Nodeを得る。コンテンツなどの値は、Propertyとして、そのノードにsetPropertyすることで、入るわけなのね。ふむふむ、JackrabbitのTransientRepositoryを使って試しているが、日本語のノードとか作っても化けることはないみたい。すばらしい。リポジトリの中身を見てみると、ノード名とかが実際のファイル名とかになることはないみたいだ。XMLファイル内にそれらが保存されている。なるほどなるほど。これを使いこなせると便利だね～。気になるのは、Credentailsはウェブアプリではどう管理するのがよいのだろうか。そこがよくわからんので、まだ、実践投入ができん。一応、JCR の JavaDoc を眺めてみると、バージョン管理もできるっぽいから、これはいいかもね～。うむ、面白そうだ。
カテゴリー: Java
GC
最新のものは、どうなのかわからんが、簡単にGCについて、まとめる。ヒープ領域は以下のような感じになっている。
| <--- ヒープメモリー ---> | | <--- NEW ---> | <--- OLD ---> | | <--- Eden Space ---> | <--- Survivor Space ---> | <--- Tenured Gen ---> |
ヒープメモリーは、NEW領域とOLD領域に分けることができる。NEWには、比較的新しいオブジェクトが入り、OLDには、結構、長生きしているオブジェクトが入っている。つまり、オブジェクトは、まず、NEWに入れられて、そこからOLDに移るという感じ。
っで、NEW領域をさらにEdenとSuvivorに分けることができる。基本的には、オブジェクトはEdenに入り、Scavenge GC(Full GCでないやつ。つまり、すばやく動いてくれるやつね)が走って、Suvivorに移る。そんで、NEW領域で32回、Scavenge GCを食らって生き残ったやつがOLDに移る。そんでもって、OLDがいっぱいになるとFull GCみたいな感じかね。
そんでもって、パラメータについては、
| <--- -Xms, -Xmx ---> | | <--- -XX:NewSize,-XX:MaxNewSize ---> | <--- OLD ---> | | <--- Eden Space ---> | <--- Survivor Space ---> | <--- Tenured Gen ---> | -XX:SuvivorRatio=Eden Space/Suvivor Space
と言う感じ。NEW領域のサイズは、ヒープ全体の1/4～1/3が良いみたい。ソースコードとか見たわけではないので、実際にはもっといろいろとチューニングする点はあるのかもしれないが・・・。つっこみや情報などありましたら、ぜひとも、お願いします 🙂
PermGen space
Jetspeed でノートパッドポートレットを利用していて、そのエラーが起きるのだが、どうも、Sun の AMD 64bit Javaを利用すると発生する。32 bit だと問題ないのだけど・・・。ノートパッドポートレットは、Hibernate+Seasar2+MyFacesという構成だが、Hibernateまわりが怪しいのかな・・・。何が原因だろうか・・・。
参考情報
http://www.intra-mart.jp/download/doc/OutOfMemoryError.html
いろいろと調べてみる。状況を確認するには、-Dcom.sun.management.jmxremoteのjavaオプションを付けて実行して、jconsole でみるとわかりやすいかね。どうもみていると、Hibernate+Searsar2+MyFacesの構成のポートレットを読み込むと、PermGenが10Mくらいずつあがっていくような・・・。確かに、Hibernate関連で、無駄にjarファイルを登録しているからな・・・、絞らないとダメだな、これは。でも、ヒーブ関連もいっぱいになっているな・・・。JSF でコードを書くときにセッションも絞り込んだ方がいいのかも。うむむ、これを見ていると、反省すべき点がいろいろと見つかるな・・・。確か、以前、J2もjarファイルをウェブコンテナの方にまとめようという話もあったと思うし。そうしないと、たくさんポートレットを配備したりすると、PermGenとかあっさり超えるような。