From nakai.norihisa ＠ yes.nttcom.ne.jp Wed Feb 6 10:03:19 2008 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Wed, 06 Feb 2008 10:03:19 +0900 Subject: [Ultramonkey-l7-develop 134] Re: =?iso-2022-jp?b?WxskQiVtJTA5YkVZMj0bKEJdbG9nNGN4eC0wLjkuNw==?= =?iso-2022-jp?b?GyRCJEskRCQtJF4kNyRGGyhC?= In-Reply-To: <47A83974.2040804@yes.nttcom.ne.jp> References: <47A83974.2040804@yes.nttcom.ne.jp> Message-ID: <47A90757.40603@yes.nttcom.ne.jp> 中居です。 お疲れ様です。 ちらっと見た感じでは0.9.7と0.10.0ではlocale周りでの仕様変更が入っているみたいですね。 exsample. using namespace log4cxx; using namespcae log4cxx::helpers; LoggerPtr logger(Logger::getLogger("sample")); std::locale::gloal(new std::locale("japanese")); wchar_t str = L"あいうえお"; LOG4CXX_DEBUG( logger, str ); みたいなコードが通るみたいですが、gccにおいてはstd::locale::globalでjapaneseを 指定してもSystemLocaleとは"まったく無関係"なので(コンパイル状態でコードセットが決まる) euc-jp環境ではeuc-jpに、UTF-8ではUTF-8になるので、あまり使われない (と、言うかそもそもgnu系でのiconvのようにlocale関係はまだまだ弱い) 及び、今回のUltraMonkey-L7での文字列扱いは全てUS-ASCIIなのでlocale関係の仕様変更に関しては 考慮外でかまわないかと思います。 > UltraMonkey-L7 Develop の皆様 > > 高丸です。 > > 現在、新Loggerで使用しているlog4cxx-0.9.7ですが、 > x86-64の環境でバグが多いことが分かりました。 > > http://mail-archives.apache.org/mod_mbox/logging-log4cxx-user/200507.mbox/%3c2FE9BCAD-51AB-43BE-AF6D-88351145BCB6 ＠ apache.org%3e > > log4cxxの公式サイトからtarballで取得できるバージョンが0.9.7で > あったため、新Loggerでも0.9.7を使用しようとしていたのですが、 > 実際にLoggerの開発過程で不安定さを感じることが多々ありました。 > SVNリポジトリから取得できる0.10版ではそうしたメモリ周りの > バグが改善されているようです。 > > 0.10の取得方法がSVNのみというのがネックになるかと思いますが、 > 移行しておいた方が全体の品質という点でよろしいかと思われます。 > > 以上につきましてご意見を宜しくお願いいたします。 > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > > From nakai.norihisa ＠ yes.nttcom.ne.jp Wed Feb 6 10:33:01 2008 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Wed, 06 Feb 2008 10:33:01 +0900 Subject: [Ultramonkey-l7-develop 135] =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklGGyRCJEsbKEI=?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= Message-ID: <47A90E4D.9070901@yes.nttcom.ne.jp> TO:皆様 中居です。 レポジトリに画面周りにjspがあがっております。 画面構成や挙動についてはjspを見ていただくことにして、 servletコンテナからl7vsadm等コマンド系へのIFについて、現在考察しているところです。 単純に考えた場合には 「l7vsadmをforkして標準出力をもらいparseして解釈する」 のが一番楽なのでしょうが、この場合fork()のボトルネックが懸念されます。 apache等でもCGIがmod*系になっているように単純forkのボトルネックは かなり大きめです。 以前3秒に1度psを発行するCアプリでしたが、systemへのボトルネックが大きく、 /procをサーチするように変更したところかなりの改善の経験もあります。 したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 ラッパとする.soを作成し、JNIでのアクセスを検討しております。 JNI経由ならばforkのようなボトルネックは存在しませんし、 単純に皮をかぶせるだけなので小変更ですみます。 どうぞよろしくお願いいたします。 From takebayashi.shinya ＠ nttcom.co.jp Wed Feb 6 12:52:19 2008 From: takebayashi.shinya ＠ nttcom.co.jp (Shinya TAKEBAYASHI) Date: Wed, 6 Feb 2008 12:52:19 +0900 Subject: [Ultramonkey-l7-develop 136] Re: =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklG?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <47A90E4D.9070901@yes.nttcom.ne.jp> References: <47A90E4D.9070901@yes.nttcom.ne.jp> Message-ID: <20080206125219.aa56d95b.takebayashi.shinya@nttcom.co.jp> 中居 様 竹林です． お疲れ様です． > したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 > ラッパとする.soを作成し、JNIでのアクセスを検討しております。 l7vsadm も so 経由で使うようにする，という認識で良いですか？ +---------+ | l7vsadm +---+ +---------+ | +------------+ +-----------+ +---+ l7vsadm.so +----+ l7vsd | +---------+ | +------------+ +-----------+ | l7gui +---+ +---------+ ----------------------------------------------------------- NTT コムウェア株式会社 基盤技術本部 OSS 推進部 OSS 適用担当 竹林 信哉（たけばやし しんや） 〒261-0023 千葉市美浜区中瀬 1-6 NTT 幕張ビル 21F En TEL: 043-211-2452 (+383-8054) E-mail: takebayashi.shinya ＠ nttcom.co.jp GPG ID: 70298B55 GPG FP: 98C3 25CF 8201 4881 9328 5C91 CBFA DCFC 7029 8B55 ----------------------------------------------------------- *** nakai norihisa wrote in message <47A90E4D.9070901 ＠ yes.nttcom.ne.jp> *** Date: Wed, 06 Feb 2008 10:33:01 +0900 *** Subject: [Ultramonkey-l7-develop 135] l7guiの既存部分とのIFについて > TO:皆様 > > 中居です。 > レポジトリに画面周りにjspがあがっております。 > 画面構成や挙動についてはjspを見ていただくことにして、 > servletコンテナからl7vsadm等コマンド系へのIFについて、現在考察しているところです。 > > 単純に考えた場合には > > 「l7vsadmをforkして標準出力をもらいparseして解釈する」 > > のが一番楽なのでしょうが、この場合fork()のボトルネックが懸念されます。 > apache等でもCGIがmod*系になっているように単純forkのボトルネックは > かなり大きめです。 > > 以前3秒に1度psを発行するCアプリでしたが、systemへのボトルネックが大きく、 > /procをサーチするように変更したところかなりの改善の経験もあります。 > > したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 > ラッパとする.soを作成し、JNIでのアクセスを検討しております。 > > JNI経由ならばforkのようなボトルネックは存在しませんし、 > 単純に皮をかぶせるだけなので小変更ですみます。 > > どうぞよろしくお願いいたします。 > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > From nakai.norihisa ＠ yes.nttcom.ne.jp Wed Feb 6 13:51:30 2008 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Wed, 06 Feb 2008 13:51:30 +0900 Subject: [Ultramonkey-l7-develop 137] Re: =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklG?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20080206125219.aa56d95b.takebayashi.shinya@nttcom.co.jp> References: <47A90E4D.9070901@yes.nttcom.ne.jp> <20080206125219.aa56d95b.takebayashi.shinya@nttcom.co.jp> Message-ID: <47A93CD2.2050203@yes.nttcom.ne.jp> 竹林様 中居です。 お疲れ様です。 l7vsadm.soにadmの機能を入れることはちょっと難しいと思います。 「共有ライブラリ側を複数呼出に対応する必要がある」 　→複数のプロセスからひとつのインスタンスに呼び出しが入るので 　　lockの関係を考慮するプログラムにする必要がある ですので、l7vsadm.cを 1)mainのあるファイル 2)今までのmainがある(int l7vsadm_main( int argc, char* argv[] )の関数)ファイル に分離して、JNI用so側で2)をリンクしようと考えています。 したがって、図を直すとすれば +---------+ | l7vsadm +------------------+ +---------+ | +-----------+ +--+ l7vsd | +---------+ +------------+ | +-----------+ | l7gui +---+ admjni.so +-+ +---------+ +------------+ と、なりますね。 現状のl7vsadmの中でsocketの使用中のリトライ&タイムアウトを 考慮しているのでl7vsadm.so側で複数呼び出しコードを追加するよりは 修正コストが低いと思われます。 どうぞよろしくお願いいたします。 > 中居 様 > > > 竹林です． > お疲れ様です． > > >> したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 >> ラッパとする.soを作成し、JNIでのアクセスを検討しております。 > > l7vsadm も so 経由で使うようにする，という認識で良いですか？ > > +---------+ > | l7vsadm +---+ > +---------+ | +------------+ +-----------+ > +---+ l7vsadm.so +----+ l7vsd | > +---------+ | +------------+ +-----------+ > | l7gui +---+ > +---------+ > > ----------------------------------------------------------- > NTT コムウェア株式会社 > 基盤技術本部 OSS 推進部 OSS 適用担当 > > 竹林 信哉（たけばやし しんや） > > 〒261-0023 千葉市美浜区中瀬 1-6 NTT 幕張ビル 21F En > TEL: 043-211-2452 (+383-8054) > E-mail: takebayashi.shinya ＠ nttcom.co.jp > GPG ID: 70298B55 > GPG FP: 98C3 25CF 8201 4881 9328 5C91 CBFA DCFC 7029 8B55 > ----------------------------------------------------------- > > *** nakai norihisa wrote in message <47A90E4D.9070901 ＠ yes.nttcom.ne.jp> > *** Date: Wed, 06 Feb 2008 10:33:01 +0900 > *** Subject: [Ultramonkey-l7-develop 135] l7guiの既存部分とのIFについて > >> TO:皆様 >> >> 中居です。 >> レポジトリに画面周りにjspがあがっております。 >> 画面構成や挙動についてはjspを見ていただくことにして、 >> servletコンテナからl7vsadm等コマンド系へのIFについて、現在考察しているところです。 >> >> 単純に考えた場合には >> >> 「l7vsadmをforkして標準出力をもらいparseして解釈する」 >> >> のが一番楽なのでしょうが、この場合fork()のボトルネックが懸念されます。 >> apache等でもCGIがmod*系になっているように単純forkのボトルネックは >> かなり大きめです。 >> >> 以前3秒に1度psを発行するCアプリでしたが、systemへのボトルネックが大きく、 >> /procをサーチするように変更したところかなりの改善の経験もあります。 >> >> したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 >> ラッパとする.soを作成し、JNIでのアクセスを検討しております。 >> >> JNI経由ならばforkのようなボトルネックは存在しませんし、 >> 単純に皮をかぶせるだけなので小変更ですみます。 >> >> どうぞよろしくお願いいたします。 >> >> _______________________________________________ >> Ultramonkey-l7-develop mailing list >> Ultramonkey-l7-develop ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop >> > > > From takebayashi.shinya ＠ nttcom.co.jp Wed Feb 6 14:39:08 2008 From: takebayashi.shinya ＠ nttcom.co.jp (Shinya TAKEBAYASHI) Date: Wed, 6 Feb 2008 14:39:08 +0900 Subject: [Ultramonkey-l7-develop 138] Re: =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklG?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <47A93CD2.2050203@yes.nttcom.ne.jp> References: <47A90E4D.9070901@yes.nttcom.ne.jp> <20080206125219.aa56d95b.takebayashi.shinya@nttcom.co.jp> <47A93CD2.2050203@yes.nttcom.ne.jp> Message-ID: <20080206143908.73ad3a92.takebayashi.shinya@nttcom.co.jp> 竹林です． > ですので、l7vsadm.cを > 1)mainのあるファイル > 2)今までのmainがある(int l7vsadm_main( int argc, char* argv[] )の関数)ファイル > に分離して、JNI用so側で2)をリンクしようと考えています。 > > したがって、図を直すとすれば > > +---------+ > | l7vsadm +------------------+ > +---------+ | +-----------+ > +--+ l7vsd | > +---------+ +------------+ | +-----------+ > | l7gui +---+ admjni.so +-+ > +---------+ +------------+ F 更コスト，保守性，アトミック性はどのように考えていらっしゃいますか． 何を気にしているかというと…… ★ ポイント 1： ソースファイルの依存関係 中居さんの考えでは，「2」のソースファイルを admdmn.c と仮定した場合， l7vsadm: l7vsadm.c admcmn.c admjni.so: admjni.c admcmn.c という依存関係が発生します． ★ ポイント 2： ファイルの居所 admjni.so は l7gui でしか使わないので，admjni.c は l7gui のパッケージに入ります． ★ ポイント 3： パッケージの頒布形式 l7gui は l7vsd と別のパッケージで頒布されます． ★ ポイント 4： l7gui は Web アプリ l7gui は Java アプリケーションであり，インストール（デプロイ）時に gcc 等を使ってコンパイルすることは好ましくありません． ポイント 1 とポイント 2，ポイント 2 とポイント 4は矛盾の関係にあるので， 何かしら措置を執る必要があります． 一番簡単な解決策は中居さんの案の「2」にあたる部分を 両パッケージに入れる方法ですが，アトミック性が低下するためボツです． かといって，l7vsd の中に admjni.c を入れた場合は，l7gui を使うためにも l7vsd のソースコード一式が必要になります． 加えて，l7vsd を rpm パッケージでインストールした場合の対処なども 未検討のような気がします． ------------------ 以上のことを考え ○ l7vsd との通信を行う関数をまとめた共有オブジェクト （admjni.so と仮定）を作成 ○ l7vsadm は admjni.so を通して l7vsd と通信する ○ l7gui は，admjni.so を通して l7vsd と通信する ○ admjni.so のソースである admjni.c を l7vsd のパッケージに入れる （rpm 化した場合でも，l7vsd のパッケージに admjni.so が入るので l7gui をインストールする場合でも再コンパイルの必要がない） とすることで，「保守性」「アトミック性」の保障ができると考えています． ----------------------------------------------------------- NTT コムウェア株式会社 基盤技術本部 OSS 推進部 OSS 適用担当 竹林 信哉（たけばやし しんや） 〒261-0023 千葉市美浜区中瀬 1-6 NTT 幕張ビル 21F En TEL: 043-211-2452 (+383-8054) E-mail: takebayashi.shinya ＠ nttcom.co.jp GPG ID: 70298B55 GPG FP: 98C3 25CF 8201 4881 9328 5C91 CBFA DCFC 7029 8B55 ----------------------------------------------------------- *** nakai norihisa wrote in message <47A93CD2.2050203 ＠ yes.nttcom.ne.jp> *** Date: Wed, 06 Feb 2008 13:51:30 +0900 *** Subject: [Ultramonkey-l7-develop 137] Re: l7guiの既存部分とのIFについて > 竹林様 > 中居です。 > お疲れ様です。 > > l7vsadm.soにadmの機能を入れることはちょっと難しいと思います。 > > 「共有ライブラリ側を複数呼出に対応する必要がある」 > 　→複数のプロセスからひとつのインスタンスに呼び出しが入るので > 　　lockの関係を考慮するプログラムにする必要がある > > ですので、l7vsadm.cを > 1)mainのあるファイル > 2)今までのmainがある(int l7vsadm_main( int argc, char* argv[] )の関数)ファイル > に分離して、JNI用so側で2)をリンクしようと考えています。 > > したがって、図を直すとすれば > > +---------+ > | l7vsadm +------------------+ > +---------+ | +-----------+ > +--+ l7vsd | > +---------+ +------------+ | +-----------+ > | l7gui +---+ admjni.so +-+ > +---------+ +------------+ > > と、なりますね。 > 現状のl7vsadmの中でsocketの使用中のリトライ&タイムアウトを > 考慮しているのでl7vsadm.so側で複数呼び出しコードを追加するよりは > 修正コストが低いと思われます。 > > どうぞよろしくお願いいたします。 > > > > 中居 様 > > > > > > 竹林です． > > お疲れ様です． > > > > > >> したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 > >> ラッパとする.soを作成し、JNIでのアクセスを検討しております。 > > > > l7vsadm も so 経由で使うようにする，という認識で良いですか？ > > > > +---------+ > > | l7vsadm +---+ > > +---------+ | +------------+ +-----------+ > > +---+ l7vsadm.so +----+ l7vsd | > > +---------+ | +------------+ +-----------+ > > | l7gui +---+ > > +---------+ > > > > ----------------------------------------------------------- > > NTT コムウェア株式会社 > > 基盤技術本部 OSS 推進部 OSS 適用担当 > > > > 竹林 信哉（たけばやし しんや） > > > > 〒261-0023 千葉市美浜区中瀬 1-6 NTT 幕張ビル 21F En > > TEL: 043-211-2452 (+383-8054) > > E-mail: takebayashi.shinya ＠ nttcom.co.jp > > GPG ID: 70298B55 > > GPG FP: 98C3 25CF 8201 4881 9328 5C91 CBFA DCFC 7029 8B55 > > ----------------------------------------------------------- > > > > *** nakai norihisa wrote in message <47A90E4D.9070901 ＠ yes.nttcom.ne.jp> > > *** Date: Wed, 06 Feb 2008 10:33:01 +0900 > > *** Subject: [Ultramonkey-l7-develop 135] l7guiの既存部分とのIFについて > > > >> TO:皆様 > >> > >> 中居です。 > >> レポジトリに画面周りにjspがあがっております。 > >> 画面構成や挙動についてはjspを見ていただくことにして、 > >> servletコンテナからl7vsadm等コマンド系へのIFについて、現在考察しているところです。 > >> > >> 単純に考えた場合には > >> > >> 「l7vsadmをforkして標準出力をもらいparseして解釈する」 > >> > >> のが一番楽なのでしょうが、この場合fork()のボトルネックが懸念されます。 > >> apache等でもCGIがmod*系になっているように単純forkのボトルネックは > >> かなり大きめです。 > >> > >> 以前3秒に1度psを発行するCアプリでしたが、systemへのボトルネックが大きく、 > >> /procをサーチするように変更したところかなりの改善の経験もあります。 > >> > >> したがって、現状l7vsadm等のIFをそのまま使うわけではなく、 > >> ラッパとする.soを作成し、JNIでのアクセスを検討しております。 > >> > >> JNI経由ならばforkのようなボトルネックは存在しませんし、 > >> 単純に皮をかぶせるだけなので小変更ですみます。 > >> > >> どうぞよろしくお願いいたします。 > >> > >> _______________________________________________ > >> Ultramonkey-l7-develop mailing list > >> Ultramonkey-l7-develop ＠ lists.sourceforge.jp > >> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > >> > > > > > > > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > From nakai.norihisa ＠ yes.nttcom.ne.jp Wed Feb 6 15:20:09 2008 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Wed, 06 Feb 2008 15:20:09 +0900 Subject: [Ultramonkey-l7-develop 139] Re: =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklG?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20080206143908.73ad3a92.takebayashi.shinya@nttcom.co.jp> References: <47A90E4D.9070901@yes.nttcom.ne.jp> <20080206125219.aa56d95b.takebayashi.shinya@nttcom.co.jp> <47A93CD2.2050203@yes.nttcom.ne.jp> <20080206143908.73ad3a92.takebayashi.shinya@nttcom.co.jp> Message-ID: <47A95199.2040807@yes.nttcom.ne.jp> 中居です。 > ポイント 1 とポイント 2，ポイント 2 とポイント 4は矛盾の関係にあるので， > 何かしら措置を執る必要があります． > 一番簡単な解決策は中居さんの案の「2」にあたる部分を > 両パッケージに入れる方法ですが，アトミック性が低下するためボツです． > かといって，l7vsd の中に admjni.c を入れた場合は，l7gui を使うためにも > l7vsd のソースコード一式が必要になります． > 加えて，l7vsd を rpm パッケージでインストールした場合の対処なども > 未検討のような気がします． 依存関係にかんしてはおおむね同意です。 これはl7vsd側が口を持つべきだと思います。 (ただ、l7guiを使うには必ずl7vsdが必要ですので、l7vsdをrpm install時に admjndi.soをinstallするように考慮すればよい気がします) > ○ l7vsd との通信を行う関数をまとめた共有オブジェクト > （admjni.so と仮定）を作成 > ○ l7vsadm は admjni.so を通して l7vsd と通信する > ○ l7gui は，admjni.so を通して l7vsd と通信する > ○ admjni.so のソースである admjni.c を l7vsd のパッケージに入れる > （rpm 化した場合でも，l7vsd のパッケージに admjni.so が入るので > l7gui をインストールする場合でも再コンパイルの必要がない） > とすることで，「保守性」「アトミック性」の保障ができると考えています． ただ、l7vsadmがadmjni.soを使う必要性はありませんね。 l7vsadm自体はそのままsocketを利用する仕様でよいと思います。 admjni.soのコードをl7vsd側のパッケージに入れる部分でアトミック性は確保できるでしょう。 したがって、l7vsd側のパッケージにjni用の.soを追加するというのがベターな気がします。 と、ここまで書いて思ったのですがやはりl7vsd側に入れるのは問題が発生しそうです。 現状Cluster側の表示を行う部分でもjni用soが必要なのですが、 l7vsd自体どのクラスタソフトを使用するかと言うのは固定できないと思います。 lifekeeperかも知れませんし、HB2かもしれません。 現状その部分についてはJNDIでの名前解決で差し替え可能に設計を進めていますが、 ここもjniを利用したIFの口を持つ必要があります。 すると、上記パッケージの場所はどこにするのがベターなのかと言う問題にぶち当たります。 l7vsdの中にhb2jni.soが入るのはなしですよね? 別途、独立してかつ、各l7vsdやHB2にあわせたjniのパッケージを用意するのが ベターのようが気がしてきました。 ただ、この問題はもう少し掘り下げて考えなくてはならないと思いますので、 何か良い案がありましたらご意見いただけますと幸いです。 どうぞよろしくお願いいたします。 From kondo.hideaki ＠ oss.ntt.co.jp Wed Feb 6 16:09:43 2008 From: kondo.hideaki ＠ oss.ntt.co.jp (Hideaki Kondo) Date: Wed, 06 Feb 2008 16:09:43 +0900 Subject: [Ultramonkey-l7-develop 140] Re: =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklG?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <47A95199.2040807@yes.nttcom.ne.jp> References: <20080206143908.73ad3a92.takebayashi.shinya@nttcom.co.jp> <47A95199.2040807@yes.nttcom.ne.jp> Message-ID: <20080206153846.D4A6.KONDO.HIDEAKI@oss.ntt.co.jp> 中居様 (Cc:竹林様、関係各位) 近藤です。 お疲れ様です。 標記の件に関連して、内容を十分に確認しきれていないので 少しズレているかも知れませんが、forkの処理コストを考慮して JNIでl7guiとl7vsadm,l7vsd,Heartbeat2等とのインタフェースを 取ることを考えつつあるように思いますが、そもそもUM-L7の 運用始めた後でfork処理コストが負荷分散処理に影響を与えるほど GUIから（定期的な発行はあるにしても）呼び出して使うことが あるのかが疑問です。 Heartbeatは複数プロセスで構成されていますが、JNIで簡単に インタフェースがとれるかどうかも懸念されますし、 他クラスタソフトとの連携においても、コマンドベースでの インタフェースに比べて差し替えが容易な構造を維持できるかも （クラスの作り方でカプセル化はできると思いますが）心配です。 また、連携される側のソフト(Heartbeat等)が何も意識しないで インタフェースをとれるのかも気になります。 個人的にはコマンドベースのインタフェースで統一してもらった方が 構造としてもシンプルでわかり易いですし、差替えも容易と考えられる ので、forkの処理コストのみを心配して、JNIで処理する構造とする 方針には、（十分に理解できていないので）賛同しかねている状況です。 JNIを利用することのメリットだけでなく、デメリット面もあるよう でしたら、その点をご教授いただく必要があると思います。 On Wed, 06 Feb 2008 15:20:09 +0900 nakai norihisa wrote: > 中居です。 > > > > ポイント 1 とポイント 2，ポイント 2 とポイント 4は矛盾の関係にあるので， > > 何かしら措置を執る必要があります． > > 一番簡単な解決策は中居さんの案の「2」にあたる部分を > > 両パッケージに入れる方法ですが，アトミック性が低下するためボツです． > > かといって，l7vsd の中に admjni.c を入れた場合は，l7gui を使うためにも > > l7vsd のソースコード一式が必要になります． > > 加えて，l7vsd を rpm パッケージでインストールした場合の対処なども > > 未検討のような気がします． > > 依存関係にかんしてはおおむね同意です。 > これはl7vsd側が口を持つべきだと思います。 > (ただ、l7guiを使うには必ずl7vsdが必要ですので、l7vsdをrpm install時に > admjndi.soをinstallするように考慮すればよい気がします) > > > > ○ l7vsd との通信を行う関数をまとめた共有オブジェクト > > （admjni.so と仮定）を作成 > > ○ l7vsadm は admjni.so を通して l7vsd と通信する > > ○ l7gui は，admjni.so を通して l7vsd と通信する > > ○ admjni.so のソースである admjni.c を l7vsd のパッケージに入れる > > （rpm 化した場合でも，l7vsd のパッケージに admjni.so が入るので > > l7gui をインストールする場合でも再コンパイルの必要がない） > > とすることで，「保守性」「アトミック性」の保障ができると考えています． > > ただ、l7vsadmがadmjni.soを使う必要性はありませんね。 > l7vsadm自体はそのままsocketを利用する仕様でよいと思います。 > admjni.soのコードをl7vsd側のパッケージに入れる部分でアトミック性は確保できるでしょう。 > > したがって、l7vsd側のパッケージにjni用の.soを追加するというのがベターな気がします。 > > と、ここまで書いて思ったのですがやはりl7vsd側に入れるのは問題が発生しそうです。 > 現状Cluster側の表示を行う部分でもjni用soが必要なのですが、 > l7vsd自体どのクラスタソフトを使用するかと言うのは固定できないと思います。 > lifekeeperかも知れませんし、HB2かもしれません。 > 現状その部分についてはJNDIでの名前解決で差し替え可能に設計を進めていますが、 > ここもjniを利用したIFの口を持つ必要があります。 > > すると、上記パッケージの場所はどこにするのがベターなのかと言う問題にぶち当たります。 > l7vsdの中にhb2jni.soが入るのはなしですよね? > > 別途、独立してかつ、各l7vsdやHB2にあわせたjniのパッケージを用意するのが > ベターのようが気がしてきました。 > > ただ、この問題はもう少し掘り下げて考えなくてはならないと思いますので、 > 何か良い案がありましたらご意見いただけますと幸いです。 > > どうぞよろしくお願いいたします。 > 以上よろしくお願いします。 -- Hideaki Kondo（近藤 秀明)