ファーストホップとセカンドホップを試してみる。なるほど、JCRは、Reposityがそのリポジトリの情報で、ReposityにCredentialsを渡すことで、そのリポジトリにアクセスするためのSessionを得られるのか。っで、そのセッションを使って、Nodeを得る。コンテンツなどの値は、Propertyとして、そのノードにsetPropertyすることで、入るわけなのね。ふむふむ、JackrabbitのTransientRepositoryを使って試しているが、日本語のノードとか作っても化けることはないみたい。すばらしい。リポジトリの中身を見てみると、ノード名とかが実際のファイル名とかになることはないみたいだ。XMLファイル内にそれらが保存されている。なるほどなるほど。これを使いこなせると便利だね～。気になるのは、Credentailsはウェブアプリではどう管理するのがよいのだろうか。そこがよくわからんので、まだ、実践投入ができん。一応、JCR の JavaDoc を眺めてみると、バージョン管理もできるっぽいから、これはいいかもね～。うむ、面白そうだ。
xml:lang, RFC 1766, RFC 3066
Jetspeed にxml:langに関して、バグがあがっていたので確認してみる。xml:langはRFC 1766の表記法に従うのね。つまり、en-USとか_でないやつ。ついつい、_にしたくなるところだが。っで、1766の更新版が3066のよう。だから、今は、3066に従うのが正しいみたい。
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が良いみたい。ソースコードとか見たわけではないので、実際にはもっといろいろとチューニングする点はあるのかもしれないが・・・。つっこみや情報などありましたら、ぜひとも、お願いします 🙂