BEA World2005Tokyo開催中

何気に今週は行きたいイベントだらけだったりする。
月曜はLibertyAllianceのイベントがあり
火曜・水曜はBEAWorld2005
水曜から土曜日まではWPC ExpoとかSecuritySolutionとか色々。
どれも行きたいけど時間がないんだよねぇ。。。


という余談はさておき、BEA JRockitです。
障害解析などを行う上で動かしながら様々な解析データを取得できる機能が盛り込まれており、HPのSDKと同様に複数のGarbage Collectionをサポートしている事からJBossなどOSSJava製品はこのJavaVMを利用することでよりGCにより一時的に停止する事なく動作中の検証データを取得できるようになるかもしれない。
これは非常に有益なことだと思います。

ちなみに(SunSDKと比較しても)性能が高いことで定評があるようなのですが、RHEL上で利用したときにJVMのバグに遭遇したことがあるので安定性という面では記事中にあるようなミッションクリティカルなシステムで利用するにはまだまだ時期尚早という感は正直なところあります。*1
BEA JRockitの開発・メンテナンスはスウェーデンの企業を買収して入手したこともあり、未だにスウェーデンで行っているっぽいです。製品自体の開発拠点としては米国と中国がメインだと思うのですがJRockitに関してはスウェーデン
つまり、WebLogic単体やそれが動作させるJVMを一つの開発拠点で同時に見ることが出来ないということになります。それに日本BEAのエンジニアがどこまでコアに触れられるかという事がわからないのでそれがある程度明確にならない限りは、ユーザは問題が発生したときに即座に対応を始めることは期待出来ないという事を認識する必要があると思う。
そもそも、J2EEサーバを利用しているユーザ*2は利用する上で知っておくべきリスクについて疎すぎると思う。*3JVMで問題が発生したときにはJVM自体の修正が出来ない場合や出来ても時間が掛かるかもしれないことを認識した上で、どのパッケージ・クラスを利用するか、そのパッケージ・クラスで問題が発生したときに代替処理はどのような設計で行うかなどを意識する必要があり、問題が発生したときにはせめてスレッドダンプを数秒間隔で数回は取得するなどの対策を用意しておくべきだと思う。

こう考えてしまう理由は、そういう人たちを多く見てきているからに他ならないんだけど、
便利な製品が出れば出るほど使いたがる人ってのはその便利さの影でリスクが潜在的に潜んでいることを認識しないからタチが悪い。。。

*1:これについては以前書いたとおり、Javaをミッションクリティカルなシーンに利用する事に対して疑問を持っているからに他ならないんですが・・・

*2:というかSE

*3:J2EEサーバに限った話ではないけど