top / index / prev / next / target / source
2005-09-06 diary: blancoResourceBundle正式版リリース , Javaリモートデバッグ , Eclipseプラグインのリモートデバッグ方法
日記形式でつづる いがぴょんコラム ウェブページです。
blancoResourceBundle正式版リリース , Javaリモートデバッグ , Eclipseプラグインのリモートデバッグ方法
Excel様式からプロパティファイルを自動生成するblancoResourceBundleの初の正式版リリースです。
blancoResourceBundle正式版リリース
Excel様式からプロパティファイルやJavaソースコードを自動生成する blancoResourceBundleの初の正式版がリリースです。
私個人としても、このツールは かなり気に入っています。文字列に含まれる情報を java.text.MessageFormatクラスをうまく活用することにより置換文字列を検知しているあたりは、純粋に素晴らしいと思います。こういったところに最低限の設定入力によって 最大限の効果を引き出すという blancoDbでのノウハウが生きています。(とりあえず置換文字列の検出を、自前で書いていないところがポイントですね…)
blancoWsdlモックアップ作成
blancoSOAPの中に blancoWsdlのモックアップを追加で作成しました。(2005.09.10変更 blancoWsdlは blancoSOAPのサブプロジェクトということで落ち着きました) Excelブックに電文定義などをおこない、それから WSDLを自動生成するという たあいのないものですが、WSDLがニガテな私はとっても重宝します。
フィールドチェックを (シンプル型定義あるいはコンプレックス型定義として) 生成すべきかどうかについての検討を実施中です。実際のところ xsdにいろいろ書いても SOAP実装が応じてくれない可能性もあります。
blancoDb Enterprise Editionプラグイン、ブラッシュアップ中
blancoDb Enterprise Edition プラグインにバグなどを見つけ、修正などをおこないました。
それとは別に メモリリークしている模様です (T_T) プラグイン化して初めて顕在化しているのでしょう。Antタスクで毎回プロセスが終了していた頃には、正直なところ気がつきませんでした。2005.09.10後日談 このバグは 現時点では EclipseのJFace APIのバグによるメモリリークである模様との結論で考えています。
リモートデバッグ
そんなことで、リモートデバッグできるプロファイラを探索中です。
はて、J2SE 5.0以降には標準搭載されていたような話を聞いたような気がしますが、すぐには思い出せません。
Java Platform Debugger Architecture http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/jpda/index.html ここからたどっていけるのかしら…
jconsole.exe これだったような気も…、、、はて、あらためて jdkのbinフォルダを見たら、全く認識したことがないコマンドが多数…。勉強しなおさないと これはフォローできませぬ。
関係しそうなリンクをメモしておきます。
Java開発の問題解決を助ける: プロファイラでメモリリークとパフォーマンス問題を解決 http://www.atmarkit.co.jp/fjava/rensai3/debug02/debug02_1.html
第6回 Eclipseをプロファイラとして活用する http://www.atmarkit.co.jp/fjava/rensai2/eclipse2_06/eclipse06_1.html
2005.09.08 読者のmarsさんからのツッコミ
Subject:プロファイラをお探しのようですが...はじめまして、いまい(mars)です。いつも日記拝見させてもらってます。トラックバック送れないのでメールにて失礼しますが、リモートで監視できるプロファイラをお探しのようですが、NetBeans Profilerをオススメします。軽いしフリーだし、Solarisでも使えるしベンリです。
ここからいがぴょんツッコミありがとうございます。わたしもmarsさんの日記は いつも拝見させていただいております。 NetBeans Profiler、ぜひ試してみます。
Eclipseプラグインのリモートデバッグ方法
2005.09.08追記 Eclipseプラグインをリモートデバッグするための方法を下記にメモしておきます。J2SE 5.0の基本機能を用いた方法になります。パッケージソフトなど追加ソフトを何も入れずに解析ということで、緊急時の対応方法になります (気の利いたパッケージソフトを利用して解析した方が、ずっと楽な場合があります)。いずれも Eclipse 3.1で動作確認を取りました。
Java Press vol.41 p43, 55の記事を参考にさせていただきました。この号、メモリ関連で困っている私に超ヒットしました。vol.41はまさにメモリ特集号ですね。これだけのJavaメモリ関連情報が集まっているのは非常に価値があると思います。
Eclipseプラグインをjconsoleを用いてメモリ状況監視を行う方法
Eclipseを jmxremoteオプション付きで起動します。 eclipse -vmargs -Dcom.sun.management.jmxremote
コマンドプロンプトから jconsoleを起動します。 jconsole [改行]
jconsoleから[接続]を行います。 jmxremoteオプション付きで起動した Eclipseが一覧に出てくるので、それを選んで [接続] を行います。
Eclipseプラグインを hprofを利用してプロファイリングする方法
Eclipseを -Xrunhprofオプション付きで起動します。 eclipse -clean -vm "C:\Program Files\Java\jdk1.5.0_03\bin\java.exe" -vmargs -Xrunhprof:heap=sites,depth=10
Eclipse に -vmargsを用いて JavaVM用の引数を引き渡します。
メモリ上の巨大なメモリゴミを発見したいので、heap=sitesオプションを付けます。
ある程度の長さのスタックトレースが欲しいので depth=10 (ここでは10階層までのスタックトレースを取得するという意味) を指定します。 ただし、あまり深いスタックトレースを指定すると、とっても動作が遅くなります。
※hprofのオプションは java -Xrunhprof:help で調べることができます。
プロファイリングを行いたいタイミングで、CTRL+Breakを押します。 CTRL+Breakを実行してしばらく後、java.hprof.txtテキストファイルの中身をチェックすることができます。
プロセスを正規のルートで終了させます。 これで、プロセス終了時点でのメモリ状況がjava.hprof.txtテキストファイルに格納されます。
テキストファイル内の SITESのトップ10くらいを見て、まずそうなエントリのスレッドを番号をもとに検索し、該当スレッドのスタックトレースをチェックします。
これで、おおよそのメモリリーク箇所は把握できます。
この日記について
- ホームページ更新者: 伊賀 敏樹 / Tosiki Iga
- Diary / Facebook / LinkedIn / GitHub / Qiita / Mastodon / X(Twitter) / Amazon / Share on Twitter / top / いがぴょんについて / Powered by Igapyonv3
- 本サイトの見解は、私 個人のものであり、株式会社レザボア・コンサルティング は当個人的見解に一切責任を持ちません。