kai-devel-ja Mailing List for kai (Page 2)

Kai is a distributed key-value datastore

Status: Beta

Brought to you by: takemaru

kai-devel-ja — For Kai developers in Japanese

You can subscribe to this list here.

2008	_Jan	_Feb	_Mar	_Apr	_May (14)	_Jun (95)	_Jul (94)	_Aug (44)	_Sep (5)	_Oct (8)	_Nov (14)	_Dec (6)
2009	_Jan	_Feb (18)	_Mar (19)	_Apr	_May (11)	_Jun (8)	_Jul (4)	_Aug	_Sep (3)	_Oct	_Nov	_Dec
2011	_Jan	_Feb	_Mar (1)	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec

Flat | Threaded

<< < 1 2 3 4 .. 14 > >> (Page 2 of 14)

Re: [Kai-devel-ja] リファクタリング

From: masahito i. <coo...@gm...> - 2009-05-23 14:02:08

> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．

非同期にすると、信頼性が落ちそうなので
MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが
如何でしょうか？

他に、TC を使う等で書き込み速度自体を上げる手もありそうですが
ポートを使った場合、ノード全体がロックされてボトルネックになるかも？
後で、検証しないと・・・。

> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．

バージョン番号が 1.0 に到達していないので
後方互換を保つ事の優先順位を下げる事に一票入れておきます。
＃とは言いつつ、ユーザの声は大切ですよね・・・。

2009/5/22 Takeru INOUE <tak...@gm...>:
> コードの整理やテストの充実のために，リファクタリングしようと思っています．
> そのための branch を作りました．
>
> branches/takemaru_refactoring/
>
> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．
> 後者については，同期のための CPU 負荷が高いという声を耳にしたので．
>
> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．
> 並行して考えていきます．
>
> --
> Takeru INOUE
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



-- 
cooldaemon

[Kai-devel-ja] リファクタリング

From: Takeru I. <tak...@gm...> - 2009-05-22 12:39:02

コードの整理やテストの充実のために，リファクタリングしようと思っています．
そのための branch を作りました．

branches/takemaru_refactoring/

その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．
後者については，同期のための CPU 負荷が高いという声を耳にしたので．

別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．
並行して考えていきます．

-- 
Takeru INOUE

Re: [Kai-devel-ja] stats

From: shunichi s. <shi...@gm...> - 2009-03-25 23:30:25

2009/3/25 Takeru INOUE <tak...@gm...>:
> お疲れ様でした．
> 一部のノードが落ちた状態でのテストはしていませんが，基本的な機能は大丈夫っぽいです．

ソース&動作確認ありがとうございます。

> kai_unreconciled_get に続く配列数(?) は，N に合わせて変更するのがいいでしょうか?

その通りですね m(_ _)m
修正 & コミット(trunk) しました。

-- 
shino

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-25 11:07:13

お疲れ様でした．
一部のノードが落ちた状態でのテストはしていませんが，基本的な機能は大丈夫っぽいです．

kai_unreconciled_get に続く配列数(?) は，N に合わせて変更するのがいいでしょうか?

2009/3/24 shunichi shinohara <shi...@gm...>:
> しのはらです。
>
> 2009/2/16 Takeru INOUE <tak...@gm...>:
>> 内部的に 2つのバージョンが返ってきたことが 3 回あり，そのうち 1回は解消できなかった．
>> さらに，3つのバージョンが返ってきたことが 1回あったけど，解消できた．
>>
>> kai_unreconciled_get 1(3) 0(1)
>>
>> というのではどうでしょう．
>>
>
> という形で実装してみました。
> ブランチでやるほどでもないかと思ったのでいきなり trunk にコミットしました。
> # ちょっとドキドキ f(--)
>
> コメントなどありましたらツッコミおねがいします m(_ _)m
>
> --
> shino
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: shunichi s. <shi...@gm...> - 2009-03-24 02:49:14

しのはらです。

2009/2/16 Takeru INOUE <tak...@gm...>:
> 内部的に 2つのバージョンが返ってきたことが 3 回あり，そのうち 1回は解消できなかった．
> さらに，3つのバージョンが返ってきたことが 1回あったけど，解消できた．
>
> kai_unreconciled_get 1(3) 0(1)
>
> というのではどうでしょう．
>

という形で実装してみました。
ブランチでやるほどでもないかと思ったのでいきなり trunk にコミットしました。
# ちょっとドキドキ f(--)

コメントなどありましたらツッコミおねがいします m(_ _)m

-- 
shino

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-23 14:35:22

お疲れ様でした．

リビジョン番号は気にしないでいいんじゃないでしょうか．
数が多い方が，プロジェクトが活発にみえるし :-)


2009/3/22 masahito ikuta <coo...@gm...>:
> Merge とテストが終わったので、trunk にコミットしました。
> 不備がありましたら、ご指摘をお願いいたします。
>
> ちなみに・・・git で merge した後に rebase したら branch 側の commit が
> そのまま trunk へ適用されてしまい、無駄にリビジョン番号を上げてしまいました。
>
> という事で、今後は、svn コマンドに切り替えます。
> 申し訳ございませんでした。
>
> 2009/3/22 Takeru INOUE <tak...@gm...>:
>> 2009/3/21 masahito ikuta <coo...@gm...>:
>>>>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>>>
>>> 早速、こちらでコミットしておきました。
>>> そろそろ、trunk へ Merge しようかと思いますが如何でしょうか？
>>
>> はい．接続数が正しく増減することも確認しました．
>> お願いします．
>>
>>> 2009/3/21 Takeru INOUE <tak...@gm...>:
>>>> 2009/3/21 masahito ikuta <coo...@gm...>:
>>>>> 返信が遅くなって申し訳ございませんでした。
>>>>>
>>>>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>>>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>>>
>>>>> 後で warning が出ないよう修正する予定で忘れていました。
>>>>>
>>>>> badarith 例外は catch されない場合、Erlang Shell ごと落ちるのですが
>>>>> （おかげで、gen_server の Callback 関数内で発生すると、その Supervisor も巻き添えで落ちます）
>>>>> exit/1、error/1、throw/1、fault/1 どれを利用しても
>>>>> 意図的に Erlang Shell を落とす事ができませんでした。
>>>>
>>>> あぁ，そうかぁ．
>>>> なんとなく不可解だけど，しかたないですねぇ．
>>>>
>>>>> そこで、下記のようにしようかと考えております。
>>>>>
>>>>> ----------
>>>>> % ..snip..
>>>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>>>    division(1, 0), % badarith
>>>>>    {close, <<"error\r\n">>, State};
>>>>> % ..snip..
>>>>>
>>>>> division(A, B) -> A / B.
>>>>> ----------
>>>>>
>>>>> これで、コンパイル時に warning が発生しなくなります。
>>>>> 如何でしょうか？（まだ、コミットはしていません）
>>>>
>>>> いいんじゃないでしょうか．
>>>> 新しく関数を定義しなくても，↓ でもいけるっぽいです．
>>>>
>>>>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>>>>
>>>> このほうが，意図が明確になるかな?
>>>>> 2009/3/19 Takeru INOUE <tak...@gm...>:
>>>>>> お疲れ様でした．
>>>>>> ざっと確認しました．
>>>>>>
>>>>>> ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．
>>>>>>
>>>>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>>>>    BadArith = 1/0,
>>>>>>    {close, <<"error\r\n">>, State};
>>>>>>
>>>>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>>>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>>>>
>>>>>> # 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．
>>>>>>
>>>>>> 2009/3/19 masahito ikuta <coo...@gm...>:
>>>>>>> 大変、長らくお待たせ致しました。
>>>>>>> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>>>>>>>
>>>>>>> 2009/3/16 Takeru INOUE <tak...@gm...>:
>>>>>>>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>>>>>>>  bad_info:4
>>>>>>>>>
>>>>>>>>> 今、手元に開発機(MBP)が無いので
>>>>>>>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>>>>>>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>>>>>>>
>>>>>>>>> 後で、CentOS や FreeBSD でも試してみますが
>>>>>>>>> 接続直後に接続数を取得している為
>>>>>>>>> sleep を少し入れると 5 が取れるかもしれません。
>>>>>>>>
>>>>>>>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>>>>>>>
>>>>>>>>  timer:sleep(100),
>>>>>>>>
>>>>>>>> を追加したらテストに通るようになりました．
>>>>>>>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>>>>>>>> この結果を参考にしてみてください．
>>>>>>>>
>>>>>>>> # ちなみに，Leopard でテストしています．
>>>>>>>>
>>>>>>>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>>>>>>>> {kai_hash_SUITE,test2} assertion_failed
>>>>>>>>> が出る事に気がつきました。
>>>>>>>>>
>>>>>>>>> time to choose a bucket randomly: 408719 [usec]
>>>>>>>>>
>>>>>>>>> こちらの PC が重すぎるだけなんですが
>>>>>>>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>>>>>>>
>>>>>>>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>>>>>>>
>>>>>>>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>>>>>>>
>>>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>>>>>>>
>>>>>>>>>>  bad_info:4
>>>>>>>>>>
>>>>>>>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>>>>>>>> Mac Ports の Erlang です．
>>>>>>>>>>
>>>>>>>>>> cooldaemon さんのところではどうでしょうか．
>>>>>>>>>>
>>>>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>>>>>>>> お知らせ致します。
>>>>>>>>>>>
>>>>>>>>>>> お疲れ様でしたー．
>>>>>>>>>>>
>>>>>>>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>>>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>>>>>>>> stat を触る上で注意点などありましたら
>>>>>>>>>>>> お教え頂けますでしょうか？
>>>>>>>>>>>
>>>>>>>>>>> 特にないです．
>>>>>>>>>>> curr_items の後にでも追加してください．
>>>>>>>>>>>
>>>>>>>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>>>>>>>
>>>>>>>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> よろしくお願いします。
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> まだ時期尚早のようですね．．
>>>>>>>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> 補足ですが・・・
>>>>>>>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>>>>>>>> -import(ets).
>>>>>>>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>>>>>>>> 落としどころが多々あります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>>>>>>>> Package を試してみました。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 結論から先に述べると
>>>>>>>>>>>>>>> ファイル分割は行いますが
>>>>>>>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>>>>>>>> 正常に動作するのですが
>>>>>>>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>>>>>>>        Reason: {undef,
>>>>>>>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>>>>>>>                          1]},
>>>>>>>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> んー、残念。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-22 06:00:24

Merge とテストが終わったので、trunk にコミットしました。
不備がありましたら、ご指摘をお願いいたします。

ちなみに・・・git で merge した後に rebase したら branch 側の commit が
そのまま trunk へ適用されてしまい、無駄にリビジョン番号を上げてしまいました。

という事で、今後は、svn コマンドに切り替えます。
申し訳ございませんでした。

2009/3/22 Takeru INOUE <tak...@gm...>:
> 2009/3/21 masahito ikuta <coo...@gm...>:
>>>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>>
>> 早速、こちらでコミットしておきました。
>> そろそろ、trunk へ Merge しようかと思いますが如何でしょうか？
>
> はい．接続数が正しく増減することも確認しました．
> お願いします．
>
>> 2009/3/21 Takeru INOUE <tak...@gm...>:
>>> 2009/3/21 masahito ikuta <coo...@gm...>:
>>>> 返信が遅くなって申し訳ございませんでした。
>>>>
>>>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>>
>>>> 後で warning が出ないよう修正する予定で忘れていました。
>>>>
>>>> badarith 例外は catch されない場合、Erlang Shell ごと落ちるのですが
>>>> （おかげで、gen_server の Callback 関数内で発生すると、その Supervisor も巻き添えで落ちます）
>>>> exit/1、error/1、throw/1、fault/1 どれを利用しても
>>>> 意図的に Erlang Shell を落とす事ができませんでした。
>>>
>>> あぁ，そうかぁ．
>>> なんとなく不可解だけど，しかたないですねぇ．
>>>
>>>> そこで、下記のようにしようかと考えております。
>>>>
>>>> ----------
>>>> % ..snip..
>>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>>    division(1, 0), % badarith
>>>>    {close, <<"error\r\n">>, State};
>>>> % ..snip..
>>>>
>>>> division(A, B) -> A / B.
>>>> ----------
>>>>
>>>> これで、コンパイル時に warning が発生しなくなります。
>>>> 如何でしょうか？（まだ、コミットはしていません）
>>>
>>> いいんじゃないでしょうか．
>>> 新しく関数を定義しなくても，↓ でもいけるっぽいです．
>>>
>>>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>>>
>>> このほうが，意図が明確になるかな?
>>>> 2009/3/19 Takeru INOUE <tak...@gm...>:
>>>>> お疲れ様でした．
>>>>> ざっと確認しました．
>>>>>
>>>>> ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．
>>>>>
>>>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>>>    BadArith = 1/0,
>>>>>    {close, <<"error\r\n">>, State};
>>>>>
>>>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>>>
>>>>> # 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．
>>>>>
>>>>> 2009/3/19 masahito ikuta <coo...@gm...>:
>>>>>> 大変、長らくお待たせ致しました。
>>>>>> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>>>>>>
>>>>>> 2009/3/16 Takeru INOUE <tak...@gm...>:
>>>>>>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>>>>>>  bad_info:4
>>>>>>>>
>>>>>>>> 今、手元に開発機(MBP)が無いので
>>>>>>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>>>>>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>>>>>>
>>>>>>>> 後で、CentOS や FreeBSD でも試してみますが
>>>>>>>> 接続直後に接続数を取得している為
>>>>>>>> sleep を少し入れると 5 が取れるかもしれません。
>>>>>>>
>>>>>>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>>>>>>
>>>>>>>  timer:sleep(100),
>>>>>>>
>>>>>>> を追加したらテストに通るようになりました．
>>>>>>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>>>>>>> この結果を参考にしてみてください．
>>>>>>>
>>>>>>> # ちなみに，Leopard でテストしています．
>>>>>>>
>>>>>>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>>>>>>> {kai_hash_SUITE,test2} assertion_failed
>>>>>>>> が出る事に気がつきました。
>>>>>>>>
>>>>>>>> time to choose a bucket randomly: 408719 [usec]
>>>>>>>>
>>>>>>>> こちらの PC が重すぎるだけなんですが
>>>>>>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>>>>>>
>>>>>>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>>>>>>
>>>>>>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>>>>>>
>>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>>>>>>
>>>>>>>>>  bad_info:4
>>>>>>>>>
>>>>>>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>>>>>>> Mac Ports の Erlang です．
>>>>>>>>>
>>>>>>>>> cooldaemon さんのところではどうでしょうか．
>>>>>>>>>
>>>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>>>>>>> お知らせ致します。
>>>>>>>>>>
>>>>>>>>>> お疲れ様でしたー．
>>>>>>>>>>
>>>>>>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>>>>>>> stat を触る上で注意点などありましたら
>>>>>>>>>>> お教え頂けますでしょうか？
>>>>>>>>>>
>>>>>>>>>> 特にないです．
>>>>>>>>>> curr_items の後にでも追加してください．
>>>>>>>>>>
>>>>>>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>>>>>>
>>>>>>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> よろしくお願いします。
>>>>>>>>>>>
>>>>>>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> まだ時期尚早のようですね．．
>>>>>>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> 補足ですが・・・
>>>>>>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>>>>>>> -import(ets).
>>>>>>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>>>>>>
>>>>>>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>>>>>>> 落としどころが多々あります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>>>>>>> Package を試してみました。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 結論から先に述べると
>>>>>>>>>>>>>> ファイル分割は行いますが
>>>>>>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>>>>>>> 正常に動作するのですが
>>>>>>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>>>>>>        Reason: {undef,
>>>>>>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>>>>>>                          1]},
>>>>>>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> んー、残念。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-21 15:40:05

2009/3/21 masahito ikuta <coo...@gm...>:
>>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>
> 早速、こちらでコミットしておきました。
> そろそろ、trunk へ Merge しようかと思いますが如何でしょうか？

はい．接続数が正しく増減することも確認しました．
お願いします．

> 2009/3/21 Takeru INOUE <tak...@gm...>:
>> 2009/3/21 masahito ikuta <coo...@gm...>:
>>> 返信が遅くなって申し訳ございませんでした。
>>>
>>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>
>>> 後で warning が出ないよう修正する予定で忘れていました。
>>>
>>> badarith 例外は catch されない場合、Erlang Shell ごと落ちるのですが
>>> （おかげで、gen_server の Callback 関数内で発生すると、その Supervisor も巻き添えで落ちます）
>>> exit/1、error/1、throw/1、fault/1 どれを利用しても
>>> 意図的に Erlang Shell を落とす事ができませんでした。
>>
>> あぁ，そうかぁ．
>> なんとなく不可解だけど，しかたないですねぇ．
>>
>>> そこで、下記のようにしようかと考えております。
>>>
>>> ----------
>>> % ..snip..
>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>    division(1, 0), % badarith
>>>    {close, <<"error\r\n">>, State};
>>> % ..snip..
>>>
>>> division(A, B) -> A / B.
>>> ----------
>>>
>>> これで、コンパイル時に warning が発生しなくなります。
>>> 如何でしょうか？（まだ、コミットはしていません）
>>
>> いいんじゃないでしょうか．
>> 新しく関数を定義しなくても，↓ でもいけるっぽいです．
>>
>>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>>
>> このほうが，意図が明確になるかな?
>>> 2009/3/19 Takeru INOUE <tak...@gm...>:
>>>> お疲れ様でした．
>>>> ざっと確認しました．
>>>>
>>>> ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．
>>>>
>>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>>    BadArith = 1/0,
>>>>    {close, <<"error\r\n">>, State};
>>>>
>>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>>
>>>> # 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．
>>>>
>>>> 2009/3/19 masahito ikuta <coo...@gm...>:
>>>>> 大変、長らくお待たせ致しました。
>>>>> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>>>>>
>>>>> 2009/3/16 Takeru INOUE <tak...@gm...>:
>>>>>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>>>>>  bad_info:4
>>>>>>>
>>>>>>> 今、手元に開発機(MBP)が無いので
>>>>>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>>>>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>>>>>
>>>>>>> 後で、CentOS や FreeBSD でも試してみますが
>>>>>>> 接続直後に接続数を取得している為
>>>>>>> sleep を少し入れると 5 が取れるかもしれません。
>>>>>>
>>>>>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>>>>>
>>>>>>  timer:sleep(100),
>>>>>>
>>>>>> を追加したらテストに通るようになりました．
>>>>>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>>>>>> この結果を参考にしてみてください．
>>>>>>
>>>>>> # ちなみに，Leopard でテストしています．
>>>>>>
>>>>>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>>>>>> {kai_hash_SUITE,test2} assertion_failed
>>>>>>> が出る事に気がつきました。
>>>>>>>
>>>>>>> time to choose a bucket randomly: 408719 [usec]
>>>>>>>
>>>>>>> こちらの PC が重すぎるだけなんですが
>>>>>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>>>>>
>>>>>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>>>>>
>>>>>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>>>>>
>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>>>>>
>>>>>>>>  bad_info:4
>>>>>>>>
>>>>>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>>>>>> Mac Ports の Erlang です．
>>>>>>>>
>>>>>>>> cooldaemon さんのところではどうでしょうか．
>>>>>>>>
>>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>>>>>> お知らせ致します。
>>>>>>>>>
>>>>>>>>> お疲れ様でしたー．
>>>>>>>>>
>>>>>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>>>>>> stat を触る上で注意点などありましたら
>>>>>>>>>> お教え頂けますでしょうか？
>>>>>>>>>
>>>>>>>>> 特にないです．
>>>>>>>>> curr_items の後にでも追加してください．
>>>>>>>>>
>>>>>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>>>>>
>>>>>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> よろしくお願いします。
>>>>>>>>>>
>>>>>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> まだ時期尚早のようですね．．
>>>>>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>>>>>
>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> 補足ですが・・・
>>>>>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>>>>>> -import(ets).
>>>>>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>>>>>
>>>>>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>>>>>
>>>>>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>>>>>> 落としどころが多々あります。
>>>>>>>>>>>>
>>>>>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>>>>>> Package を試してみました。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 結論から先に述べると
>>>>>>>>>>>>> ファイル分割は行いますが
>>>>>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>>>>>> 正常に動作するのですが
>>>>>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>>>>>        Reason: {undef,
>>>>>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>>>>>                          1]},
>>>>>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>>>>>
>>>>>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>>>>>
>>>>>>>>>>>>> んー、残念。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-21 14:15:24

>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception

早速、こちらでコミットしておきました。
そろそろ、trunk へ Merge しようかと思いますが如何でしょうか？

2009/3/21 Takeru INOUE <tak...@gm...>:
> 2009/3/21 masahito ikuta <coo...@gm...>:
>> 返信が遅くなって申し訳ございませんでした。
>>
>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>
>> 後で warning が出ないよう修正する予定で忘れていました。
>>
>> badarith 例外は catch されない場合、Erlang Shell ごと落ちるのですが
>> （おかげで、gen_server の Callback 関数内で発生すると、その Supervisor も巻き添えで落ちます）
>> exit/1、error/1、throw/1、fault/1 どれを利用しても
>> 意図的に Erlang Shell を落とす事ができませんでした。
>
> あぁ，そうかぁ．
> なんとなく不可解だけど，しかたないですねぇ．
>
>> そこで、下記のようにしようかと考えております。
>>
>> ----------
>> % ..snip..
>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>    division(1, 0), % badarith
>>    {close, <<"error\r\n">>, State};
>> % ..snip..
>>
>> division(A, B) -> A / B.
>> ----------
>>
>> これで、コンパイル時に warning が発生しなくなります。
>> 如何でしょうか？（まだ、コミットはしていません）
>
> いいんじゃないでしょうか．
> 新しく関数を定義しなくても，↓ でもいけるっぽいです．
>
>  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception
>
> このほうが，意図が明確になるかな?
>> 2009/3/19 Takeru INOUE <tak...@gm...>:
>>> お疲れ様でした．
>>> ざっと確認しました．
>>>
>>> ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．
>>>
>>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>>    BadArith = 1/0,
>>>    {close, <<"error\r\n">>, State};
>>>
>>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>>
>>> # 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．
>>>
>>> 2009/3/19 masahito ikuta <coo...@gm...>:
>>>> 大変、長らくお待たせ致しました。
>>>> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>>>>
>>>> 2009/3/16 Takeru INOUE <tak...@gm...>:
>>>>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>>>>  bad_info:4
>>>>>>
>>>>>> 今、手元に開発機(MBP)が無いので
>>>>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>>>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>>>>
>>>>>> 後で、CentOS や FreeBSD でも試してみますが
>>>>>> 接続直後に接続数を取得している為
>>>>>> sleep を少し入れると 5 が取れるかもしれません。
>>>>>
>>>>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>>>>
>>>>>  timer:sleep(100),
>>>>>
>>>>> を追加したらテストに通るようになりました．
>>>>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>>>>> この結果を参考にしてみてください．
>>>>>
>>>>> # ちなみに，Leopard でテストしています．
>>>>>
>>>>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>>>>> {kai_hash_SUITE,test2} assertion_failed
>>>>>> が出る事に気がつきました。
>>>>>>
>>>>>> time to choose a bucket randomly: 408719 [usec]
>>>>>>
>>>>>> こちらの PC が重すぎるだけなんですが
>>>>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>>>>
>>>>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>>>>
>>>>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>>>>
>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>>>>
>>>>>>>  bad_info:4
>>>>>>>
>>>>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>>>>> Mac Ports の Erlang です．
>>>>>>>
>>>>>>> cooldaemon さんのところではどうでしょうか．
>>>>>>>
>>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>>>>> お知らせ致します。
>>>>>>>>
>>>>>>>> お疲れ様でしたー．
>>>>>>>>
>>>>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>>>>> stat を触る上で注意点などありましたら
>>>>>>>>> お教え頂けますでしょうか？
>>>>>>>>
>>>>>>>> 特にないです．
>>>>>>>> curr_items の後にでも追加してください．
>>>>>>>>
>>>>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>>>>
>>>>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>>>>
>>>>>>>>
>>>>>>>>> よろしくお願いします。
>>>>>>>>>
>>>>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> まだ時期尚早のようですね．．
>>>>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>>>>
>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 補足ですが・・・
>>>>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>>>>> -import(ets).
>>>>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>>>>
>>>>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>>>>
>>>>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>>>>> 落としどころが多々あります。
>>>>>>>>>>>
>>>>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>>>>
>>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>>>>> Package を試してみました。
>>>>>>>>>>>>
>>>>>>>>>>>> 結論から先に述べると
>>>>>>>>>>>> ファイル分割は行いますが
>>>>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>>>>
>>>>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>>>>> 正常に動作するのですが
>>>>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>>>>
>>>>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>>>>        Reason: {undef,
>>>>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>>>>                          1]},
>>>>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>>>>
>>>>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>>>>
>>>>>>>>>>>> んー、残念。
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-21 14:06:52

2009/3/21 masahito ikuta <coo...@gm...>:
> 返信が遅くなって申し訳ございませんでした。
>
>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>
> 後で warning が出ないよう修正する予定で忘れていました。
>
> badarith 例外は catch されない場合、Erlang Shell ごと落ちるのですが
> （おかげで、gen_server の Callback 関数内で発生すると、その Supervisor も巻き添えで落ちます）
> exit/1、error/1、throw/1、fault/1 どれを利用しても
> 意図的に Erlang Shell を落とす事ができませんでした。

あぁ，そうかぁ．
なんとなく不可解だけど，しかたないですねぇ．

> そこで、下記のようにしようかと考えております。
>
> ----------
> % ..snip..
> handle_call(_Socket, <<"error\r\n">>, State) ->
>    division(1, 0), % badarith
>    {close, <<"error\r\n">>, State};
> % ..snip..
>
> division(A, B) -> A / B.
> ----------
>
> これで、コンパイル時に warning が発生しなくなります。
> 如何でしょうか？（まだ、コミットはしていません）

いいんじゃないでしょうか．
新しく関数を定義しなくても，↓ でもいけるっぽいです．

  (fun(X) -> 1 / X end)(0). % to throw a bad arithmetic exception

このほうが，意図が明確になるかな?
> 2009/3/19 Takeru INOUE <tak...@gm...>:
>> お疲れ様でした．
>> ざっと確認しました．
>>
>> ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．
>>
>> handle_call(_Socket, <<"error\r\n">>, State) ->
>>    BadArith = 1/0,
>>    {close, <<"error\r\n">>, State};
>>
>> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
>> (あるいは State = to_fail とか?) にしたほうがいいかも．
>>
>> # 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．
>>
>> 2009/3/19 masahito ikuta <coo...@gm...>:
>>> 大変、長らくお待たせ致しました。
>>> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>>>
>>> 2009/3/16 Takeru INOUE <tak...@gm...>:
>>>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>>>  bad_info:4
>>>>>
>>>>> 今、手元に開発機(MBP)が無いので
>>>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>>>
>>>>> 後で、CentOS や FreeBSD でも試してみますが
>>>>> 接続直後に接続数を取得している為
>>>>> sleep を少し入れると 5 が取れるかもしれません。
>>>>
>>>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>>>
>>>>  timer:sleep(100),
>>>>
>>>> を追加したらテストに通るようになりました．
>>>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>>>> この結果を参考にしてみてください．
>>>>
>>>> # ちなみに，Leopard でテストしています．
>>>>
>>>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>>>> {kai_hash_SUITE,test2} assertion_failed
>>>>> が出る事に気がつきました。
>>>>>
>>>>> time to choose a bucket randomly: 408719 [usec]
>>>>>
>>>>> こちらの PC が重すぎるだけなんですが
>>>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>>>
>>>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>>>
>>>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>>>
>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>>>
>>>>>>  bad_info:4
>>>>>>
>>>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>>>> Mac Ports の Erlang です．
>>>>>>
>>>>>> cooldaemon さんのところではどうでしょうか．
>>>>>>
>>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>>>> お知らせ致します。
>>>>>>>
>>>>>>> お疲れ様でしたー．
>>>>>>>
>>>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>>>> stat を触る上で注意点などありましたら
>>>>>>>> お教え頂けますでしょうか？
>>>>>>>
>>>>>>> 特にないです．
>>>>>>> curr_items の後にでも追加してください．
>>>>>>>
>>>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>>>
>>>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>>>
>>>>>>>
>>>>>>>> よろしくお願いします。
>>>>>>>>
>>>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>> まだ時期尚早のようですね．．
>>>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>>>
>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 補足ですが・・・
>>>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>>>> -import(ets).
>>>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>>>
>>>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>>>
>>>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>>>> 落としどころが多々あります。
>>>>>>>>>>
>>>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>>>
>>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>>>> Package を試してみました。
>>>>>>>>>>>
>>>>>>>>>>> 結論から先に述べると
>>>>>>>>>>> ファイル分割は行いますが
>>>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>>>
>>>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>>>> 正常に動作するのですが
>>>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>>>
>>>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>>>        Reason: {undef,
>>>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>>>                          1]},
>>>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>>>
>>>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>>>
>>>>>>>>>>> んー、残念。
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>
>>>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>>>
>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>
>>>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>>>
>>>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-21 13:21:55

返信が遅くなって申し訳ございませんでした。

> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
> (あるいは State = to_fail とか?) にしたほうがいいかも．

後で warning が出ないよう修正する予定で忘れていました。

badarith 例外は catch されない場合、Erlang Shell ごと落ちるのですが
（おかげで、gen_server の Callback 関数内で発生すると、その Supervisor も巻き添えで落ちます）
exit/1、error/1、throw/1、fault/1 どれを利用しても
意図的に Erlang Shell を落とす事ができませんでした。

そこで、下記のようにしようかと考えております。

----------
% ..snip..
handle_call(_Socket, <<"error\r\n">>, State) ->
    division(1, 0), % badarith
    {close, <<"error\r\n">>, State};
% ..snip..

division(A, B) -> A / B.
----------

これで、コンパイル時に warning が発生しなくなります。
如何でしょうか？（まだ、コミットはしていません）

2009/3/19 Takeru INOUE <tak...@gm...>:
> お疲れ様でした．
> ざっと確認しました．
>
> ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．
>
> handle_call(_Socket, <<"error\r\n">>, State) ->
>    BadArith = 1/0,
>    {close, <<"error\r\n">>, State};
>
> たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
> (あるいは State = to_fail とか?) にしたほうがいいかも．
>
> # 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．
>
> 2009/3/19 masahito ikuta <coo...@gm...>:
>> 大変、長らくお待たせ致しました。
>> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>>
>> 2009/3/16 Takeru INOUE <tak...@gm...>:
>>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>>  bad_info:4
>>>>
>>>> 今、手元に開発機(MBP)が無いので
>>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>>
>>>> 後で、CentOS や FreeBSD でも試してみますが
>>>> 接続直後に接続数を取得している為
>>>> sleep を少し入れると 5 が取れるかもしれません。
>>>
>>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>>
>>>  timer:sleep(100),
>>>
>>> を追加したらテストに通るようになりました．
>>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>>> この結果を参考にしてみてください．
>>>
>>> # ちなみに，Leopard でテストしています．
>>>
>>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>>> {kai_hash_SUITE,test2} assertion_failed
>>>> が出る事に気がつきました。
>>>>
>>>> time to choose a bucket randomly: 408719 [usec]
>>>>
>>>> こちらの PC が重すぎるだけなんですが
>>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>>
>>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>>
>>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>>
>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>>
>>>>>  bad_info:4
>>>>>
>>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>>> Mac Ports の Erlang です．
>>>>>
>>>>> cooldaemon さんのところではどうでしょうか．
>>>>>
>>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>>> お知らせ致します。
>>>>>>
>>>>>> お疲れ様でしたー．
>>>>>>
>>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>>> stat を触る上で注意点などありましたら
>>>>>>> お教え頂けますでしょうか？
>>>>>>
>>>>>> 特にないです．
>>>>>> curr_items の後にでも追加してください．
>>>>>>
>>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>>
>>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>>
>>>>>>
>>>>>>> よろしくお願いします。
>>>>>>>
>>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>>> まだ時期尚早のようですね．．
>>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>>
>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>> 補足ですが・・・
>>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>>> -import(ets).
>>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>>
>>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>>
>>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>>> 落としどころが多々あります。
>>>>>>>>>
>>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>>
>>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>>> Package を試してみました。
>>>>>>>>>>
>>>>>>>>>> 結論から先に述べると
>>>>>>>>>> ファイル分割は行いますが
>>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>>
>>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>>> 正常に動作するのですが
>>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>>
>>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>>        Reason: {undef,
>>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>>                          1]},
>>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>>
>>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>>
>>>>>>>>>> んー、残念。
>>>>>>>>>>
>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>
>>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>>
>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>
>>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>>
>>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>>
>>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-19 14:55:22

お疲れ様でした．
ざっと確認しました．

ところで，test/kai_tcp_server_SUITE.erl:108 が warning を出しています．

handle_call(_Socket, <<"error\r\n">>, State) ->
    BadArith = 1/0,
    {close, <<"error\r\n">>, State};

たぶん，デバッグの残りかと思うのですが，BadArith の行を削除するか，必ず fail させたいのであれば exit 的な何か
(あるいは State = to_fail とか?) にしたほうがいいかも．

# 直しちゃってもよかったのだけど，どちらの意図かわからなかったので．．

2009/3/19 masahito ikuta <coo...@gm...>:
> 大変、長らくお待たせ致しました。
> 対応が完了致しましたので、ご確認をよろしくお願い致します。
>
> 2009/3/16 Takeru INOUE <tak...@gm...>:
>> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>>  bad_info:4
>>>
>>> 今、手元に開発機(MBP)が無いので
>>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>>
>>> 後で、CentOS や FreeBSD でも試してみますが
>>> 接続直後に接続数を取得している為
>>> sleep を少し入れると 5 が取れるかもしれません。
>>
>> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>>
>>  timer:sleep(100),
>>
>> を追加したらテストに通るようになりました．
>> こういう，マシン依存性のあるテストは難しいですよねぇ．．
>> この結果を参考にしてみてください．
>>
>> # ちなみに，Leopard でテストしています．
>>
>>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>>> {kai_hash_SUITE,test2} assertion_failed
>>> が出る事に気がつきました。
>>>
>>> time to choose a bucket randomly: 408719 [usec]
>>>
>>> こちらの PC が重すぎるだけなんですが
>>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>>
>> 前にも同じことがあったので，このテストをスキップするようにしました．
>>
>> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>>
>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>> kai_tcp_server の testcase4 が失敗しています．
>>>>
>>>>  bad_info:4
>>>>
>>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>>> Mac Ports の Erlang です．
>>>>
>>>> cooldaemon さんのところではどうでしょうか．
>>>>
>>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>>> お知らせ致します。
>>>>>
>>>>> お疲れ様でしたー．
>>>>>
>>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>>> stat を触る上で注意点などありましたら
>>>>>> お教え頂けますでしょうか？
>>>>>
>>>>> 特にないです．
>>>>> curr_items の後にでも追加してください．
>>>>>
>>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>>
>>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>>
>>>>>
>>>>>> よろしくお願いします。
>>>>>>
>>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>>> まだ時期尚早のようですね．．
>>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>>
>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>> 補足ですが・・・
>>>>>>>> Package を利用しているモジュール全てに
>>>>>>>> -import(ets).
>>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>>
>>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>>> （Covered (%) 等は表示されています）
>>>>>>>> 利用は見送ろうと考えました。
>>>>>>>>
>>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>>> 落としどころが多々あります。
>>>>>>>>
>>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>>
>>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>>> Package を試してみました。
>>>>>>>>>
>>>>>>>>> 結論から先に述べると
>>>>>>>>> ファイル分割は行いますが
>>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>>
>>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>>> 正常に動作するのですが
>>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>>
>>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>>        Reason: {undef,
>>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>>                          1]},
>>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>>
>>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>>
>>>>>>>>> んー、残念。
>>>>>>>>>
>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>>
>>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>
>>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>>
>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>
>>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>>
>>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>>
>>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>
>>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>>
>>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-19 10:15:29

大変、長らくお待たせ致しました。
対応が完了致しましたので、ご確認をよろしくお願い致します。

2009/3/16 Takeru INOUE <tak...@gm...>:
> 2009/3/16 masahito ikuta <coo...@gm...>:
>>>  bad_info:4
>>
>> 今、手元に開発機(MBP)が無いので
>> 取り急ぎ iMac で試した所、特に問題ありませんでした。
>> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>>
>> 後で、CentOS や FreeBSD でも試してみますが
>> 接続直後に接続数を取得している為
>> sleep を少し入れると 5 が取れるかもしれません。
>
> testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，
>
>  timer:sleep(100),
>
> を追加したらテストに通るようになりました．
> こういう，マシン依存性のあるテストは難しいですよねぇ．．
> この結果を参考にしてみてください．
>
> # ちなみに，Leopard でテストしています．
>
>> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
>> {kai_hash_SUITE,test2} assertion_failed
>> が出る事に気がつきました。
>>
>> time to choose a bucket randomly: 408719 [usec]
>>
>> こちらの PC が重すぎるだけなんですが
>> もう少し、甘めの数値にして頂く事は可能でしょうか？
>
> 前にも同じことがあったので，このテストをスキップするようにしました．
>
> # trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．
>
>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>> kai_tcp_server の testcase4 が失敗しています．
>>>
>>>  bad_info:4
>>>
>>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>>> Mac Ports の Erlang です．
>>>
>>> cooldaemon さんのところではどうでしょうか．
>>>
>>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>>> お知らせ致します。
>>>>
>>>> お疲れ様でしたー．
>>>>
>>>>> 少し Source が汚れたのでリファクタリングした後
>>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>>> stat を触る上で注意点などありましたら
>>>>> お教え頂けますでしょうか？
>>>>
>>>> 特にないです．
>>>> curr_items の後にでも追加してください．
>>>>
>>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>>
>>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>>
>>>>
>>>>> よろしくお願いします。
>>>>>
>>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>>> まだ時期尚早のようですね．．
>>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>>
>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>> 補足ですが・・・
>>>>>>> Package を利用しているモジュール全てに
>>>>>>> -import(ets).
>>>>>>> を追加すると、テストは全てパスします。
>>>>>>>
>>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>>> Coverage log からソースコードが参照できないので
>>>>>>> （Covered (%) 等は表示されています）
>>>>>>> 利用は見送ろうと考えました。
>>>>>>>
>>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>>> 落としどころが多々あります。
>>>>>>>
>>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>>
>>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>>> Package を試してみました。
>>>>>>>>
>>>>>>>> 結論から先に述べると
>>>>>>>> ファイル分割は行いますが
>>>>>>>> Package 対応は止めようと思います。
>>>>>>>>
>>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>>> 正常に動作するのですが
>>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>>
>>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>>        Reason: {undef,
>>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>>                         [cover_internal_data_table,
>>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>>                          1]},
>>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>>                     {test_server,my_apply,3},
>>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>>
>>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>>
>>>>>>>> んー、残念。
>>>>>>>>
>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>>
>>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>
>>>>>>>>>> では、Package を採用してみます。
>>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>>
>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>
>>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>>
>>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>>
>>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>>
>>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>
>>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>>
>>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>>
>>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>>
>>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>>> kai_store.erl
>>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>>
>>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>>
>>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>>
>>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-16 14:27:33

2009/3/16 masahito ikuta <coo...@gm...>:
>>  bad_info:4
>
> 今、手元に開発機(MBP)が無いので
> 取り急ぎ iMac で試した所、特に問題ありませんでした。
> （iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）
>
> 後で、CentOS や FreeBSD でも試してみますが
> 接続直後に接続数を取得している為
> sleep を少し入れると 5 が取れるかもしれません。

testcase4/1 の kai_tcp_server:info/1 を呼ぶ前に，

  timer:sleep(100),

を追加したらテストに通るようになりました．
こういう，マシン依存性のあるテストは難しいですよねぇ．．
この結果を参考にしてみてください．

# ちなみに，Leopard でテストしています．

> ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
> {kai_hash_SUITE,test2} assertion_failed
> が出る事に気がつきました。
>
> time to choose a bucket randomly: 408719 [usec]
>
> こちらの PC が重すぎるだけなんですが
> もう少し、甘めの数値にして頂く事は可能でしょうか？

前にも同じことがあったので，このテストをスキップするようにしました．

# trunk/ を更新したけど，branches/cooldaemon_... のほうにしとけばよかったかな．．

> 2009/3/15 Takeru INOUE <tak...@gm...>:
>> kai_tcp_server の testcase4 が失敗しています．
>>
>>  bad_info:4
>>
>> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
>> Mac Ports の Erlang です．
>>
>> cooldaemon さんのところではどうでしょうか．
>>
>> 2009/3/15 Takeru INOUE <tak...@gm...>:
>>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>>> お知らせ致します。
>>>
>>> お疲れ様でしたー．
>>>
>>>> 少し Source が汚れたのでリファクタリングした後
>>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>>> stat を触る上で注意点などありましたら
>>>> お教え頂けますでしょうか？
>>>
>>> 特にないです．
>>> curr_items の後にでも追加してください．
>>>
>>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>>
>>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>>
>>>
>>>> よろしくお願いします。
>>>>
>>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>>> まだ時期尚早のようですね．．
>>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>>
>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>> 補足ですが・・・
>>>>>> Package を利用しているモジュール全てに
>>>>>> -import(ets).
>>>>>> を追加すると、テストは全てパスします。
>>>>>>
>>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>>> Coverage log からソースコードが参照できないので
>>>>>> （Covered (%) 等は表示されています）
>>>>>> 利用は見送ろうと考えました。
>>>>>>
>>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>>> 落としどころが多々あります。
>>>>>>
>>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>>
>>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>>> Package を試してみました。
>>>>>>>
>>>>>>> 結論から先に述べると
>>>>>>> ファイル分割は行いますが
>>>>>>> Package 対応は止めようと思います。
>>>>>>>
>>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>>> 正常に動作するのですが
>>>>>>> Common Test が Package と相性が悪いようで
>>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>>
>>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>>        Reason: {undef,
>>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>>                         [cover_internal_data_table,
>>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>>                          1]},
>>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>>                     {test_server,my_apply,3},
>>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>>
>>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>>
>>>>>>> んー、残念。
>>>>>>>
>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>>
>>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>
>>>>>>>>> では、Package を採用してみます。
>>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>>
>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>
>>>>>>>>> まだ、コードを追ってませんが
>>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>>
>>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>>
>>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>>
>>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>
>>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>>
>>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>>
>>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>>
>>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>>> kai_store.erl
>>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> 井上です．
>>>>>>>>>>>>
>>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>>
>>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>>
>>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>>
>>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>>
>>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> 皆様
>>>>>>>>>>>>>
>>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>>
>>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>>
>>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>>
>>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>>
>>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>>
>>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>>
>>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-16 01:24:47

>  bad_info:4

今、手元に開発機(MBP)が無いので
取り急ぎ iMac で試した所、特に問題ありませんでした。
（iMac の環境は、OSX 10.4.11、Erlang 5.6.3 です）

後で、CentOS や FreeBSD でも試してみますが
接続直後に接続数を取得している為
sleep を少し入れると 5 が取れるかもしれません。

ちなみに、上記のテスト中（OSX 10.4.11、Erlang 5.6.3 ）に
{kai_hash_SUITE,test2} assertion_failed
が出る事に気がつきました。

time to choose a bucket randomly: 408719 [usec]

こちらの PC が重すぎるだけなんですが
もう少し、甘めの数値にして頂く事は可能でしょうか？

2009/3/15 Takeru INOUE <tak...@gm...>:
> kai_tcp_server の testcase4 が失敗しています．
>
>  bad_info:4
>
> どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
> Mac Ports の Erlang です．
>
> cooldaemon さんのところではどうでしょうか．
>
> 2009/3/15 Takeru INOUE <tak...@gm...>:
>> 2009/3/15 masahito ikuta <coo...@gm...>:
>>> kai_tcp_server から curr_connections を取得できるようになりましたので
>>> お知らせ致します。
>>
>> お疲れ様でしたー．
>>
>>> 少し Source が汚れたのでリファクタリングした後
>>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>>> stat を触る上で注意点などありましたら
>>> お教え頂けますでしょうか？
>>
>> 特にないです．
>> curr_items の後にでも追加してください．
>>
>>> （例えば、curr_connections という名前じゃない方が良いなど）
>>
>> memcache と同じく curr_connections でいいんじゃないでしょうか．
>>
>>
>>> よろしくお願いします。
>>>
>>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>>> まだ時期尚早のようですね．．
>>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>>
>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>> 補足ですが・・・
>>>>> Package を利用しているモジュール全てに
>>>>> -import(ets).
>>>>> を追加すると、テストは全てパスします。
>>>>>
>>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>>> Coverage log からソースコードが参照できないので
>>>>> （Covered (%) 等は表示されています）
>>>>> 利用は見送ろうと考えました。
>>>>>
>>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>>> 落としどころが多々あります。
>>>>>
>>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>>
>>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>>> Package を試してみました。
>>>>>>
>>>>>> 結論から先に述べると
>>>>>> ファイル分割は行いますが
>>>>>> Package 対応は止めようと思います。
>>>>>>
>>>>>> 実際に kai を起動して手動テストを行うと
>>>>>> 正常に動作するのですが
>>>>>> Common Test が Package と相性が悪いようで
>>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>>
>>>>>> === ERROR! init_per_testcase crashed!
>>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>>        Reason: {undef,
>>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>>                         [cover_internal_data_table,
>>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>>                          1]},
>>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>>                     {test_server,my_apply,3},
>>>>>>                     {test_server,init_per_testcase,3},
>>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>>
>>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>>
>>>>>> んー、残念。
>>>>>>
>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>>
>>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>
>>>>>>>> では、Package を採用してみます。
>>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>>
>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>
>>>>>>>> まだ、コードを追ってませんが
>>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>>
>>>>>>>> stats を trunk に Merge を確認した後
>>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>>
>>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>>
>>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>
>>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>>
>>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>>
>>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>>
>>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>>> kai_store.erl
>>>>>>>>>> kai_store/dets.erl
>>>>>>>>>> kai_store/ets.erl
>>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> 井上です．
>>>>>>>>>>>
>>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>>
>>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>>
>>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>>
>>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>>
>>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> 皆様
>>>>>>>>>>>>
>>>>>>>>>>>> 幾田です。
>>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>>
>>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>>
>>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>>
>>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>>
>>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>>
>>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>>
>>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>>
>>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>>
>>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>>
>>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-15 12:59:56

kai_tcp_server の testcase4 が失敗しています．

  bad_info:4

どうやら，5 つのプロセスを期待しているのに 4 つになっているようですね．
Mac Ports の Erlang です．

cooldaemon さんのところではどうでしょうか．

2009/3/15 Takeru INOUE <tak...@gm...>:
> 2009/3/15 masahito ikuta <coo...@gm...>:
>> kai_tcp_server から curr_connections を取得できるようになりましたので
>> お知らせ致します。
>
> お疲れ様でしたー．
>
>> 少し Source が汚れたのでリファクタリングした後
>> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
>> stat を触る上で注意点などありましたら
>> お教え頂けますでしょうか？
>
> 特にないです．
> curr_items の後にでも追加してください．
>
>> （例えば、curr_connections という名前じゃない方が良いなど）
>
> memcache と同じく curr_connections でいいんじゃないでしょうか．
>
>
>> よろしくお願いします。
>>
>> 2009/3/1 Takeru INOUE <tak...@gm...>:
>>> まだ時期尚早のようですね．．
>>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>>
>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>> 補足ですが・・・
>>>> Package を利用しているモジュール全てに
>>>> -import(ets).
>>>> を追加すると、テストは全てパスします。
>>>>
>>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>>> Coverage log からソースコードが参照できないので
>>>> （Covered (%) 等は表示されています）
>>>> 利用は見送ろうと考えました。
>>>>
>>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>>> 落としどころが多々あります。
>>>>
>>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>>
>>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>>> Package を試してみました。
>>>>>
>>>>> 結論から先に述べると
>>>>> ファイル分割は行いますが
>>>>> Package 対応は止めようと思います。
>>>>>
>>>>> 実際に kai を起動して手動テストを行うと
>>>>> 正常に動作するのですが
>>>>> Common Test が Package と相性が悪いようで
>>>>> make test を実行すると、下記のエラーが出ます。
>>>>>
>>>>> === ERROR! init_per_testcase crashed!
>>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>>        Reason: {undef,
>>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>>                         [cover_internal_data_table,
>>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>>                          1]},
>>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>>                     {test_server,my_apply,3},
>>>>>                     {test_server,init_per_testcase,3},
>>>>>                     {test_server,run_test_case_eval1,4},
>>>>>                     {test_server,run_test_case_eval,6}]}
>>>>>
>>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>>
>>>>> んー、残念。
>>>>>
>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>>
>>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>
>>>>>>> では、Package を採用してみます。
>>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>>
>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>
>>>>>>> まだ、コードを追ってませんが
>>>>>>> 私の環境では、正常に動作しています。
>>>>>>>
>>>>>>> stats を trunk に Merge を確認した後
>>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>>
>>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>>
>>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>
>>>>>>>>> ご返信ありがとうございます。
>>>>>>>>>
>>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>>
>>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>>
>>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>>> kai_store.erl
>>>>>>>>> kai_store/dets.erl
>>>>>>>>> kai_store/ets.erl
>>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> 井上です．
>>>>>>>>>>
>>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>>
>>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>>
>>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>>
>>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>>
>>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 皆様
>>>>>>>>>>>
>>>>>>>>>>> 幾田です。
>>>>>>>>>>> お疲れ様です。
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>>
>>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 案１．分割しない
>>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>>
>>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>>
>>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>>
>>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> お手数ではございますが
>>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>
>>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>>
>>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>
>>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>
>>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>>
>>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>>
>>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>>
>>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>>
>>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>>
>>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>>
>>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>> Kai...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-15 12:56:10

2009/3/15 masahito ikuta <coo...@gm...>:
> kai_tcp_server から curr_connections を取得できるようになりましたので
> お知らせ致します。

お疲れ様でしたー．

> 少し Source が汚れたのでリファクタリングした後
> kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
> stat を触る上で注意点などありましたら
> お教え頂けますでしょうか？

特にないです．
curr_items の後にでも追加してください．

> （例えば、curr_connections という名前じゃない方が良いなど）

memcache と同じく curr_connections でいいんじゃないでしょうか．


> よろしくお願いします。
>
> 2009/3/1 Takeru INOUE <tak...@gm...>:
>> まだ時期尚早のようですね．．
>> かなり地雷な気がするので，普通のファイル分割にしましょう．
>>
>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>> 補足ですが・・・
>>> Package を利用しているモジュール全てに
>>> -import(ets).
>>> を追加すると、テストは全てパスします。
>>>
>>> ただ・・・使っていない ets を、インポートしたくありませんし
>>> Coverage log からソースコードが参照できないので
>>> （Covered (%) 等は表示されています）
>>> 利用は見送ろうと考えました。
>>>
>>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>>> 落としどころが多々あります。
>>>
>>> perl っぽい階層管理で十分なのになぁ・・・。
>>>
>>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>>> 本日(3/1)、kai_stat を trunk から取り込み
>>>> Package を試してみました。
>>>>
>>>> 結論から先に述べると
>>>> ファイル分割は行いますが
>>>> Package 対応は止めようと思います。
>>>>
>>>> 実際に kai を起動して手動テストを行うと
>>>> 正常に動作するのですが
>>>> Common Test が Package と相性が悪いようで
>>>> make test を実行すると、下記のエラーが出ます。
>>>>
>>>> === ERROR! init_per_testcase crashed!
>>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>>        Reason: {undef,
>>>>                    [{'kai_tcp_server.ets',update_counter,
>>>>                         [cover_internal_data_table,
>>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>>                          1]},
>>>>                     {'kai_tcp_server.sup',start_link,4},
>>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>>                     {test_server,my_apply,3},
>>>>                     {test_server,init_per_testcase,3},
>>>>                     {test_server,run_test_case_eval1,4},
>>>>                     {test_server,run_test_case_eval,6}]}
>>>>
>>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>>
>>>> んー、残念。
>>>>
>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>> branches/takemaru_stats を trunk にマージしました．
>>>>>
>>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>
>>>>>> では、Package を採用してみます。
>>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>>
>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>
>>>>>> まだ、コードを追ってませんが
>>>>>> 私の環境では、正常に動作しています。
>>>>>>
>>>>>> stats を trunk に Merge を確認した後
>>>>>> count_current_tcp_connections にも Merge します。
>>>>>>
>>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>>
>>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>>
>>>>>>>
>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>
>>>>>>>> ご返信ありがとうございます。
>>>>>>>>
>>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>>
>>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>>
>>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>>> kai_store.erl
>>>>>>>> kai_store/dets.erl
>>>>>>>> kai_store/ets.erl
>>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>>> 井上です．
>>>>>>>>>
>>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>>
>>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>>
>>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>>
>>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>>
>>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 皆様
>>>>>>>>>>
>>>>>>>>>> 幾田です。
>>>>>>>>>> お疲れ様です。
>>>>>>>>>>
>>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>>
>>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>>
>>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 案１．分割しない
>>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>>
>>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>>
>>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 案３．パッケージを使う
>>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>>
>>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>>> kai_tcp_server.erl
>>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>>
>>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> お手数ではございますが
>>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>
>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>
>>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>>
>>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>>
>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>
>>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>
>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>
>>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>>
>>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>>
>>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>>
>>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>>
>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>>
>>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>>
>>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>>
>>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>>
>>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>>
>>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>>
>>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>>
>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>>
>>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>>
>>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>>
>>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>>
>>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>>
>>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>>
>>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>>
>>>>>>>>>>>>> 以上です。
>>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>>
>>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>> Kai...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-15 07:32:26

kai_tcp_server から curr_connections を取得できるようになりましたので
お知らせ致します。

少し Source が汚れたのでリファクタリングした後
kai_stat:all/0、kai_stat:stat/2 を修正しようと思うのですが
stat を触る上で注意点などありましたら
お教え頂けますでしょうか？

（例えば、curr_connections という名前じゃない方が良いなど）

よろしくお願いします。

2009/3/1 Takeru INOUE <tak...@gm...>:
> まだ時期尚早のようですね．．
> かなり地雷な気がするので，普通のファイル分割にしましょう．
>
> 2009/3/1 masahito ikuta <coo...@gm...>:
>> 補足ですが・・・
>> Package を利用しているモジュール全てに
>> -import(ets).
>> を追加すると、テストは全てパスします。
>>
>> ただ・・・使っていない ets を、インポートしたくありませんし
>> Coverage log からソースコードが参照できないので
>> （Covered (%) 等は表示されています）
>> 利用は見送ろうと考えました。
>>
>> また、kai_tcp_server.supervisor と言うモジュール名を付けると
>> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
>> 落としどころが多々あります。
>>
>> perl っぽい階層管理で十分なのになぁ・・・。
>>
>> 2009/3/1 masahito ikuta <coo...@gm...>:
>>> 本日(3/1)、kai_stat を trunk から取り込み
>>> Package を試してみました。
>>>
>>> 結論から先に述べると
>>> ファイル分割は行いますが
>>> Package 対応は止めようと思います。
>>>
>>> 実際に kai を起動して手動テストを行うと
>>> 正常に動作するのですが
>>> Common Test が Package と相性が悪いようで
>>> make test を実行すると、下記のエラーが出ます。
>>>
>>> === ERROR! init_per_testcase crashed!
>>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>>        Reason: {undef,
>>>                    [{'kai_tcp_server.ets',update_counter,
>>>                         [cover_internal_data_table,
>>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>>                          1]},
>>>                     {'kai_tcp_server.sup',start_link,4},
>>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>>                     {test_server,my_apply,3},
>>>                     {test_server,init_per_testcase,3},
>>>                     {test_server,run_test_case_eval1,4},
>>>                     {test_server,run_test_case_eval,6}]}
>>>
>>> Common Test のカバレッジを管理する  cover というモジュールの中で
>>> ets を利用しているようなのですが、.ets という書き方をしていない為
>>> kai_tcp_server.ets として扱われてしまっているようです。
>>>
>>> んー、残念。
>>>
>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>> branches/takemaru_stats を trunk にマージしました．
>>>>
>>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>
>>>>> では、Package を採用してみます。
>>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>>
>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>
>>>>> まだ、コードを追ってませんが
>>>>> 私の環境では、正常に動作しています。
>>>>>
>>>>> stats を trunk に Merge を確認した後
>>>>> count_current_tcp_connections にも Merge します。
>>>>>
>>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>>
>>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>>
>>>>>>
>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>
>>>>>>> ご返信ありがとうございます。
>>>>>>>
>>>>>>> 個人的には、ファイル分割をする事で
>>>>>>> メンテナンス性が上がると考えておりますので
>>>>>>> ファイル分割を行なおうと思います。
>>>>>>>
>>>>>>> Package 対応は、全体のルールに関わる為
>>>>>>> もし実験的に試しで対応するのであれば
>>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>>
>>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>>> kai_store.erl
>>>>>>> kai_store/dets.erl
>>>>>>> kai_store/ets.erl
>>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>>> 井上です．
>>>>>>>>
>>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>>
>>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>>
>>>>>>>>  kai_tcp.sup:start()
>>>>>>>>
>>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>>
>>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>>> 皆様
>>>>>>>>>
>>>>>>>>> 幾田です。
>>>>>>>>> お疲れ様です。
>>>>>>>>>
>>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>>
>>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>>
>>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>>> 如何でしょうか？
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 案１．分割しない
>>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>>
>>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>>
>>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>>> 如何でしょうか？
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 案３．パッケージを使う
>>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>>
>>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>>> kai_tcp_server.erl
>>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>>
>>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>>> 如何でしょうか？
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> お手数ではございますが
>>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>
>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>
>>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>>
>>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>>
>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>
>>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>
>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>
>>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>>
>>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>>> 少し調査させてください。
>>>>>>>>>>
>>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>>
>>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>>
>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>
>>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>>
>>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>>
>>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>>
>>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>>
>>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>>
>>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>>
>>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>>
>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>>
>>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>>
>>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>>
>>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>>
>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>>
>>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>>
>>>>>>>>>>>> gen_server である為
>>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>>
>>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>>
>>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>>
>>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>>
>>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>>
>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>>
>>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>>
>>>>>>>>>>>> 以上です。
>>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>>
>>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>
>>>>>>>>>>>>> そうです．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>>> _______________________________________________
>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>> Kai...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-03-01 12:10:33

まだ時期尚早のようですね．．
かなり地雷な気がするので，普通のファイル分割にしましょう．

2009/3/1 masahito ikuta <coo...@gm...>:
> 補足ですが・・・
> Package を利用しているモジュール全てに
> -import(ets).
> を追加すると、テストは全てパスします。
>
> ただ・・・使っていない ets を、インポートしたくありませんし
> Coverage log からソースコードが参照できないので
> （Covered (%) 等は表示されています）
> 利用は見送ろうと考えました。
>
> また、kai_tcp_server.supervisor と言うモジュール名を付けると
> supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
> 落としどころが多々あります。
>
> perl っぽい階層管理で十分なのになぁ・・・。
>
> 2009/3/1 masahito ikuta <coo...@gm...>:
>> 本日(3/1)、kai_stat を trunk から取り込み
>> Package を試してみました。
>>
>> 結論から先に述べると
>> ファイル分割は行いますが
>> Package 対応は止めようと思います。
>>
>> 実際に kai を起動して手動テストを行うと
>> 正常に動作するのですが
>> Common Test が Package と相性が悪いようで
>> make test を実行すると、下記のエラーが出ます。
>>
>> === ERROR! init_per_testcase crashed!
>>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>>        Reason: {undef,
>>                    [{'kai_tcp_server.ets',update_counter,
>>                         [cover_internal_data_table,
>>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>>                          1]},
>>                     {'kai_tcp_server.sup',start_link,4},
>>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>>                     {test_server,my_apply,3},
>>                     {test_server,init_per_testcase,3},
>>                     {test_server,run_test_case_eval1,4},
>>                     {test_server,run_test_case_eval,6}]}
>>
>> Common Test のカバレッジを管理する  cover というモジュールの中で
>> ets を利用しているようなのですが、.ets という書き方をしていない為
>> kai_tcp_server.ets として扱われてしまっているようです。
>>
>> んー、残念。
>>
>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>> branches/takemaru_stats を trunk にマージしました．
>>>
>>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>
>>>> では、Package を採用してみます。
>>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>>
>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>
>>>> まだ、コードを追ってませんが
>>>> 私の環境では、正常に動作しています。
>>>>
>>>> stats を trunk に Merge を確認した後
>>>> count_current_tcp_connections にも Merge します。
>>>>
>>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>>
>>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>>
>>>>>
>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>
>>>>>> ご返信ありがとうございます。
>>>>>>
>>>>>> 個人的には、ファイル分割をする事で
>>>>>> メンテナンス性が上がると考えておりますので
>>>>>> ファイル分割を行なおうと思います。
>>>>>>
>>>>>> Package 対応は、全体のルールに関わる為
>>>>>> もし実験的に試しで対応するのであれば
>>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>>
>>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>>> kai_store.erl
>>>>>> kai_store/dets.erl
>>>>>> kai_store/ets.erl
>>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>>> 井上です．
>>>>>>>
>>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>>
>>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>>
>>>>>>>  kai_tcp.sup:start()
>>>>>>>
>>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>>
>>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>>
>>>>>>>
>>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>>> 皆様
>>>>>>>>
>>>>>>>> 幾田です。
>>>>>>>> お疲れ様です。
>>>>>>>>
>>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>>> ご相談があり、メール致しました。
>>>>>>>>
>>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>>> モジュール内で重複してしまいました。
>>>>>>>>
>>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>>> 如何でしょうか？
>>>>>>>>
>>>>>>>>
>>>>>>>> 案１．分割しない
>>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>>
>>>>>>>>
>>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>>
>>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>>> kai_tcp_server_sup.erl
>>>>>>>> kai_tcp_server_monitor.erl
>>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>>
>>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>>> とモジュール名を選択させるよりは
>>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>>> 良いのではないかと考えておりますが
>>>>>>>> 如何でしょうか？
>>>>>>>>
>>>>>>>>
>>>>>>>> 案３．パッケージを使う
>>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>>> パッケージを階層化する方法もあります。
>>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>>
>>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>>> kai_tcp_server.erl
>>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>>> kai_tcp_server/monitor.erl
>>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>>
>>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>>> 見通しが良くなるような気もしています。
>>>>>>>> 如何でしょうか？
>>>>>>>>
>>>>>>>>
>>>>>>>> お手数ではございますが
>>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>
>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>
>>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>>
>>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>>
>>>>>>>>>>> <デメリット>
>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>
>>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>
>>>>>>>>>>> gen_server である為
>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>
>>>>>>>>>>おぉ，なるほど．
>>>>>>>>>
>>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>>> 正しく理解できていない状態で
>>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>>> 少し調査させてください。
>>>>>>>>>
>>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>>
>>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> 難しいですねぇ．
>>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>>
>>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>>
>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>
>>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>>
>>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>>
>>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>>
>>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>>
>>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>>
>>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>>
>>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>>
>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>>
>>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>>
>>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>>
>>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>>
>>>>>>>>>>> <デメリット>
>>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>>
>>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>>
>>>>>>>>>>> gen_server である為
>>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>>> 何とかなりそう？
>>>>>>>>>>
>>>>>>>>>> おぉ，なるほど．
>>>>>>>>>>
>>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>>
>>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>>
>>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>>
>>>>>>>>>>> <デメリット>
>>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>>
>>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>>
>>>>>>>>>>> 以上です。
>>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>>
>>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>>
>>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>
>>>>>>>>>>>> そうです．
>>>>>>>>>>>>
>>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>>
>>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>>
>>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>>
>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>
>>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>>> _______________________________________________
>>>>>>>> Kai-devel-ja mailing list
>>>>>>>> Kai...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-01 12:03:32

補足ですが・・・
Package を利用しているモジュール全てに
-import(ets).
を追加すると、テストは全てパスします。

ただ・・・使っていない ets を、インポートしたくありませんし
Coverage log からソースコードが参照できないので
（Covered (%) 等は表示されています）
利用は見送ろうと考えました。

また、kai_tcp_server.supervisor と言うモジュール名を付けると
supervisor モジュールは、 import しても .supervisor で呼ぶ必要があるなど
落としどころが多々あります。

perl っぽい階層管理で十分なのになぁ・・・。

2009/3/1 masahito ikuta <coo...@gm...>:
> 本日(3/1)、kai_stat を trunk から取り込み
> Package を試してみました。
>
> 結論から先に述べると
> ファイル分割は行いますが
> Package 対応は止めようと思います。
>
> 実際に kai を起動して手動テストを行うと
> 正常に動作するのですが
> Common Test が Package と相性が悪いようで
> make test を実行すると、下記のエラーが出ます。
>
> === ERROR! init_per_testcase crashed!
>        Line: {kai_tcp_server_SUITE,init_per_testcase,27}
>        Reason: {undef,
>                    [{'kai_tcp_server.ets',update_counter,
>                         [cover_internal_data_table,
>                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
>                          1]},
>                     {'kai_tcp_server.sup',start_link,4},
>                     {kai_tcp_server_SUITE,init_per_testcase,2},
>                     {test_server,my_apply,3},
>                     {test_server,init_per_testcase,3},
>                     {test_server,run_test_case_eval1,4},
>                     {test_server,run_test_case_eval,6}]}
>
> Common Test のカバレッジを管理する  cover というモジュールの中で
> ets を利用しているようなのですが、.ets という書き方をしていない為
> kai_tcp_server.ets として扱われてしまっているようです。
>
> んー、残念。
>
> 2009/2/28 Takeru INOUE <tak...@gm...>:
>> branches/takemaru_stats を trunk にマージしました．
>>
>> 2009/2/28 masahito ikuta <coo...@gm...>:
>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>
>>> では、Package を採用してみます。
>>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>>
>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>
>>> まだ、コードを追ってませんが
>>> 私の環境では、正常に動作しています。
>>>
>>> stats を trunk に Merge を確認した後
>>> count_current_tcp_connections にも Merge します。
>>>
>>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>>
>>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>>
>>>>
>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>
>>>>> ご返信ありがとうございます。
>>>>>
>>>>> 個人的には、ファイル分割をする事で
>>>>> メンテナンス性が上がると考えておりますので
>>>>> ファイル分割を行なおうと思います。
>>>>>
>>>>> Package 対応は、全体のルールに関わる為
>>>>> もし実験的に試しで対応するのであれば
>>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>>
>>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>>> kai_store.erl
>>>>> kai_store/dets.erl
>>>>> kai_store/ets.erl
>>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>>
>>>>>
>>>>>
>>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>>> 井上です．
>>>>>>
>>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>>
>>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>>
>>>>>>  kai_tcp.sup:start()
>>>>>>
>>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>>
>>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>>
>>>>>>
>>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>>> 皆様
>>>>>>>
>>>>>>> 幾田です。
>>>>>>> お疲れ様です。
>>>>>>>
>>>>>>> kai_tcp_server のモジュール構成について
>>>>>>> ご相談があり、メール致しました。
>>>>>>>
>>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>>> supervisor のコールバック関数 init/1 と
>>>>>>> gen_server のコールバック関数 init/1 が
>>>>>>> モジュール内で重複してしまいました。
>>>>>>>
>>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>>> 如何でしょうか？
>>>>>>>
>>>>>>>
>>>>>>> 案１．分割しない
>>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>>
>>>>>>>
>>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>>
>>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>>> kai_tcp_server_sup.erl
>>>>>>> kai_tcp_server_monitor.erl
>>>>>>> kai_tcp_server_acceptor.erl
>>>>>>>
>>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>>> とモジュール名を選択させるよりは
>>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>>> 良いのではないかと考えておりますが
>>>>>>> 如何でしょうか？
>>>>>>>
>>>>>>>
>>>>>>> 案３．パッケージを使う
>>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>>> パッケージを階層化する方法もあります。
>>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>>
>>>>>>> ファイルの構成は、下記を考えております。
>>>>>>> kai_tcp_server.erl
>>>>>>> kai_tcp_server/supervisor.erl
>>>>>>> kai_tcp_server/monitor.erl
>>>>>>> kai_tcp_server/acceptor.erl
>>>>>>>
>>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>>> 見通しが良くなるような気もしています。
>>>>>>> 如何でしょうか？
>>>>>>>
>>>>>>>
>>>>>>> お手数ではございますが
>>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>>
>>>>>>>
>>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>
>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>
>>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>>
>>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>>
>>>>>>>>>> <デメリット>
>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>
>>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>
>>>>>>>>>> gen_server である為
>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>> 何とかなりそう？
>>>>>>>>>
>>>>>>>>>おぉ，なるほど．
>>>>>>>>
>>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>>> 正しく理解できていない状態で
>>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>>> 少し調査させてください。
>>>>>>>>
>>>>>>>> ここは、あまり神経質にならずに
>>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>>
>>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>>> 難しいですねぇ．
>>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>>
>>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>>
>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>
>>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>>
>>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>>
>>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>>
>>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>>
>>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>>
>>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>>
>>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>>
>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>>
>>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>>
>>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>>
>>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>>
>>>>>>>>>> <デメリット>
>>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>>
>>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>>
>>>>>>>>>> gen_server である為
>>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>>> 何とかなりそう？
>>>>>>>>>
>>>>>>>>> おぉ，なるほど．
>>>>>>>>>
>>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>>
>>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>>
>>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>>
>>>>>>>>>> <デメリット>
>>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>>
>>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>>
>>>>>>>>>> 以上です。
>>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>>> よろしくお願い致します。
>>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>>
>>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>>
>>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>
>>>>>>>>>>> そうです．
>>>>>>>>>>>
>>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>>
>>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>>
>>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>>
>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>
>>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>
>>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>
>>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>>
>>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>>
>>>>>>>>>>>>> 案１．
>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>>
>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 案２．
>>>>>>>>>>>>> <方法>
>>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>>
>>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>>
>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>>> _______________________________________________
>>>>>>> Kai-devel-ja mailing list
>>>>>>> Kai...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-03-01 11:44:32

本日(3/1)、kai_stat を trunk から取り込み
Package を試してみました。

結論から先に述べると
ファイル分割は行いますが
Package 対応は止めようと思います。

実際に kai を起動して手動テストを行うと
正常に動作するのですが
Common Test が Package と相性が悪いようで
make test を実行すると、下記のエラーが出ます。

=== ERROR! init_per_testcase crashed!
	Line: {kai_tcp_server_SUITE,init_per_testcase,27}
	Reason: {undef,
                    [{'kai_tcp_server.ets',update_counter,
                         [cover_internal_data_table,
                          {bump,'kai_tcp_server.sup',start_link,4,1,28},
                          1]},
                     {'kai_tcp_server.sup',start_link,4},
                     {kai_tcp_server_SUITE,init_per_testcase,2},
                     {test_server,my_apply,3},
                     {test_server,init_per_testcase,3},
                     {test_server,run_test_case_eval1,4},
                     {test_server,run_test_case_eval,6}]}

Common Test のカバレッジを管理する  cover というモジュールの中で
ets を利用しているようなのですが、.ets という書き方をしていない為
kai_tcp_server.ets として扱われてしまっているようです。

んー、残念。

2009/2/28 Takeru INOUE <tak...@gm...>:
> branches/takemaru_stats を trunk にマージしました．
>
> 2009/2/28 masahito ikuta <coo...@gm...>:
>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>
>> では、Package を採用してみます。
>> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>>
>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>
>> まだ、コードを追ってませんが
>> 私の環境では、正常に動作しています。
>>
>> stats を trunk に Merge を確認した後
>> count_current_tcp_connections にも Merge します。
>>
>> 2009/2/28 Takeru INOUE <tak...@gm...>:
>>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>>
>>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>>
>>>
>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>
>>>> ご返信ありがとうございます。
>>>>
>>>> 個人的には、ファイル分割をする事で
>>>> メンテナンス性が上がると考えておりますので
>>>> ファイル分割を行なおうと思います。
>>>>
>>>> Package 対応は、全体のルールに関わる為
>>>> もし実験的に試しで対応するのであれば
>>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>>
>>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>>> kai_store.erl
>>>> kai_store/dets.erl
>>>> kai_store/ets.erl
>>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>>
>>>>
>>>>
>>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>>> 井上です．
>>>>>
>>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>>
>>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>>
>>>>>  kai_tcp.sup:start()
>>>>>
>>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>>
>>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>>
>>>>>
>>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>>> 皆様
>>>>>>
>>>>>> 幾田です。
>>>>>> お疲れ様です。
>>>>>>
>>>>>> kai_tcp_server のモジュール構成について
>>>>>> ご相談があり、メール致しました。
>>>>>>
>>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>>> supervisor のコールバック関数 init/1 と
>>>>>> gen_server のコールバック関数 init/1 が
>>>>>> モジュール内で重複してしまいました。
>>>>>>
>>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>>> 如何でしょうか？
>>>>>>
>>>>>>
>>>>>> 案１．分割しない
>>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>>
>>>>>>
>>>>>> 案２．振る舞い毎にモジュールを分割
>>>>>> 具体的には、下記のような構成を考えております。
>>>>>>
>>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>>> kai_tcp_server_sup.erl
>>>>>> kai_tcp_server_monitor.erl
>>>>>> kai_tcp_server_acceptor.erl
>>>>>>
>>>>>> kai_tcp_server を利用する他のモジュールに
>>>>>> 「起動したい場合は sup の関数を使う」
>>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>>> とモジュール名を選択させるよりは
>>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>>> 良いのではないかと考えておりますが
>>>>>> 如何でしょうか？
>>>>>>
>>>>>>
>>>>>> 案３．パッケージを使う
>>>>>> Scalaris くらいでしか見かけないのですが
>>>>>> パッケージを階層化する方法もあります。
>>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>>
>>>>>> ファイルの構成は、下記を考えております。
>>>>>> kai_tcp_server.erl
>>>>>> kai_tcp_server/supervisor.erl
>>>>>> kai_tcp_server/monitor.erl
>>>>>> kai_tcp_server/acceptor.erl
>>>>>>
>>>>>> 個人的には、案２で良いかとも思いますが
>>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>>> 見通しが良くなるような気もしています。
>>>>>> 如何でしょうか？
>>>>>>
>>>>>>
>>>>>> お手数ではございますが
>>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>>
>>>>>>
>>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>
>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>
>>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>>
>>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>>
>>>>>>>>> <デメリット>
>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>
>>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>
>>>>>>>>> gen_server である為
>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>> 何とかなりそう？
>>>>>>>>
>>>>>>>>おぉ，なるほど．
>>>>>>>
>>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>>> 正しく理解できていない状態で
>>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>>> 少し調査させてください。
>>>>>>>
>>>>>>> ここは、あまり神経質にならずに
>>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>>
>>>>>>> という事で、週末に案１を実装してみます。
>>>>>>>
>>>>>>>
>>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>>> 難しいですねぇ．
>>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>>
>>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>>
>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>
>>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>>
>>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>>
>>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>>
>>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>>
>>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>>
>>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>>
>>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>>
>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>>
>>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>>> デクリメントは、その逆です。
>>>>>>>>>
>>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>>
>>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>>
>>>>>>>>> <デメリット>
>>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>>
>>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>>
>>>>>>>>> gen_server である為
>>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>>> 何とかなりそう？
>>>>>>>>
>>>>>>>> おぉ，なるほど．
>>>>>>>>
>>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>>
>>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>>
>>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>>
>>>>>>>>> <デメリット>
>>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>>
>>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>>
>>>>>>>>> 以上です。
>>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>>> よろしくお願い致します。
>>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>>
>>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>>
>>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>
>>>>>>>>>> そうです．
>>>>>>>>>>
>>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>>
>>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>>
>>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>>
>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>
>>>>>>>>>> この方向で検討してみます．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>
>>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>>
>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>
>>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>>
>>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>>
>>>>>>>>>>>> 案１．
>>>>>>>>>>>> <方法>
>>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>>
>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>>
>>>>>>>>>>>> 案２．
>>>>>>>>>>>> <方法>
>>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>>
>>>>>>>>>>>> <デメリット>
>>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>>
>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>
>>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>>
>>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>>
>>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>> Kai...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>>> _______________________________________________
>>>>>> Kai-devel-ja mailing list
>>>>>> Kai...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-02-28 08:44:37

branches/takemaru_stats を trunk にマージしました．

2009/2/28 masahito ikuta <coo...@gm...>:
>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>
> では、Package を採用してみます。
> 対応後、余りにも使い難ければ、普通のファイル分割に戻します。
>
>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>
> まだ、コードを追ってませんが
> 私の環境では、正常に動作しています。
>
> stats を trunk に Merge を確認した後
> count_current_tcp_connections にも Merge します。
>
> 2009/2/28 Takeru INOUE <tak...@gm...>:
>> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
>> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>>
>> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>>
>>
>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>
>>> ご返信ありがとうございます。
>>>
>>> 個人的には、ファイル分割をする事で
>>> メンテナンス性が上がると考えておりますので
>>> ファイル分割を行なおうと思います。
>>>
>>> Package 対応は、全体のルールに関わる為
>>> もし実験的に試しで対応するのであれば
>>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>>
>>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>>> kai_store.erl
>>> kai_store/dets.erl
>>> kai_store/ets.erl
>>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>>
>>>
>>>
>>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>>> 井上です．
>>>>
>>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>>
>>>> 階層化の呼び出しはこんな風にするんですよね．
>>>>
>>>>  kai_tcp.sup:start()
>>>>
>>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>>
>>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>>
>>>>
>>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>>> 皆様
>>>>>
>>>>> 幾田です。
>>>>> お疲れ様です。
>>>>>
>>>>> kai_tcp_server のモジュール構成について
>>>>> ご相談があり、メール致しました。
>>>>>
>>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>>> supervisor のコールバック関数 init/1 と
>>>>> gen_server のコールバック関数 init/1 が
>>>>> モジュール内で重複してしまいました。
>>>>>
>>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>>> 如何でしょうか？
>>>>>
>>>>>
>>>>> 案１．分割しない
>>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>>> まだ、分割しなくとも良いかもしれません。
>>>>>
>>>>>
>>>>> 案２．振る舞い毎にモジュールを分割
>>>>> 具体的には、下記のような構成を考えております。
>>>>>
>>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>>> kai_tcp_server_sup.erl
>>>>> kai_tcp_server_monitor.erl
>>>>> kai_tcp_server_acceptor.erl
>>>>>
>>>>> kai_tcp_server を利用する他のモジュールに
>>>>> 「起動したい場合は sup の関数を使う」
>>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>>> とモジュール名を選択させるよりは
>>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>>> 良いのではないかと考えておりますが
>>>>> 如何でしょうか？
>>>>>
>>>>>
>>>>> 案３．パッケージを使う
>>>>> Scalaris くらいでしか見かけないのですが
>>>>> パッケージを階層化する方法もあります。
>>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>>
>>>>> ファイルの構成は、下記を考えております。
>>>>> kai_tcp_server.erl
>>>>> kai_tcp_server/supervisor.erl
>>>>> kai_tcp_server/monitor.erl
>>>>> kai_tcp_server/acceptor.erl
>>>>>
>>>>> 個人的には、案２で良いかとも思いますが
>>>>> パッケージを使う事で src ディレクトリ配下が
>>>>> 見通しが良くなるような気もしています。
>>>>> 如何でしょうか？
>>>>>
>>>>>
>>>>> お手数ではございますが
>>>>> ご意見の程、何卒よろしくお願い致します。
>>>>>
>>>>>
>>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>
>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>
>>>>>> erlang:monitor/2 で登録したプロセスが
>>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>>
>>>>>> Monitor の trap_exit に true を設定しておけば
>>>>>> erlang:link/1 を利用しても良いのですが
>>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>>
>>>>>>>> <デメリット>
>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>
>>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>
>>>>>>>> gen_server である為
>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>> 何とかなりそう？
>>>>>>>
>>>>>>>おぉ，なるほど．
>>>>>>
>>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>>> 正しく理解できていない状態で
>>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>>> 少し調査させてください。
>>>>>>
>>>>>> ここは、あまり神経質にならずに
>>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>>
>>>>>> という事で、週末に案１を実装してみます。
>>>>>>
>>>>>>
>>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>>> 難しいですねぇ．
>>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>>
>>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>>
>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>
>>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>>
>>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>>
>>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>>
>>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>>
>>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>>> これをフックできれば一番楽なのですが
>>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>>
>>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>>
>>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>>
>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>>
>>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>>> デクリメントは、その逆です。
>>>>>>>>
>>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>>> デクリメントの処理を行ないます。
>>>>>>>
>>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>>
>>>>>>>> <デメリット>
>>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>>
>>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>>
>>>>>>>> gen_server である為
>>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>>> 何とかなりそう？
>>>>>>>
>>>>>>> おぉ，なるほど．
>>>>>>>
>>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>>
>>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>>
>>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>>> デクリメント メッセージを送ります。
>>>>>>>>
>>>>>>>> <デメリット>
>>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>>
>>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>>
>>>>>>>> 以上です。
>>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>>> よろしくお願い致します。
>>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>>
>>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>>
>>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>
>>>>>>>>> そうです．
>>>>>>>>>
>>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>>
>>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>>> これで試してみましょうか？
>>>>>>>>>
>>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>>
>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>
>>>>>>>>> この方向で検討してみます．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>
>>>>>>>>>>> ご苦労様です！
>>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>>
>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>
>>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>>
>>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>>
>>>>>>>>>>> 案１．
>>>>>>>>>>> <方法>
>>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>>
>>>>>>>>>>> <デメリット>
>>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>>
>>>>>>>>>>> 案２．
>>>>>>>>>>> <方法>
>>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>>
>>>>>>>>>>> <デメリット>
>>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>>
>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>
>>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>>
>>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>>
>>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>>
>>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>>
>>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>>
>>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>
>>>>>>>>>>>>> shino さま:
>>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>> Kai...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>>> -Strategies to boost innovation and cut costs with open source participation
>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>>> http://p.sf.net/sfu/XcvMzF8H
>>>>> _______________________________________________
>>>>> Kai-devel-ja mailing list
>>>>> Kai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-02-28 02:25:34

> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．

では、Package を採用してみます。
対応後、余りにも使い難ければ、普通のファイル分割に戻します。

> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．

まだ、コードを追ってませんが
私の環境では、正常に動作しています。

stats を trunk に Merge を確認した後
count_current_tcp_connections にも Merge します。

2009/2/28 Takeru INOUE <tak...@gm...>:
> ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
> kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．
>
> その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．
>
>
> 2009/2/26 masahito ikuta <coo...@gm...>:
>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>
>> ご返信ありがとうございます。
>>
>> 個人的には、ファイル分割をする事で
>> メンテナンス性が上がると考えておりますので
>> ファイル分割を行なおうと思います。
>>
>> Package 対応は、全体のルールに関わる為
>> もし実験的に試しで対応するのであれば
>> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>>
>> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
>> kai_store.erl
>> kai_store/dets.erl
>> kai_store/ets.erl
>> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>>
>>
>>
>> 2009/2/26 Takeru INOUE <tak...@gm...>:
>>> 井上です．
>>>
>>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>>
>>> 階層化の呼び出しはこんな風にするんですよね．
>>>
>>>  kai_tcp.sup:start()
>>>
>>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>>
>>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>>
>>>
>>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>>> 皆様
>>>>
>>>> 幾田です。
>>>> お疲れ様です。
>>>>
>>>> kai_tcp_server のモジュール構成について
>>>> ご相談があり、メール致しました。
>>>>
>>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>>> supervisor のコールバック関数 init/1 と
>>>> gen_server のコールバック関数 init/1 が
>>>> モジュール内で重複してしまいました。
>>>>
>>>> 一応、引数のパターンマッチで逃れられるのですが
>>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>>> 如何でしょうか？
>>>>
>>>>
>>>> 案１．分割しない
>>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>>> 最終的なコード行数は、300 行程度になる予定である為
>>>> まだ、分割しなくとも良いかもしれません。
>>>>
>>>>
>>>> 案２．振る舞い毎にモジュールを分割
>>>> 具体的には、下記のような構成を考えております。
>>>>
>>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>>> kai_tcp_server_sup.erl
>>>> kai_tcp_server_monitor.erl
>>>> kai_tcp_server_acceptor.erl
>>>>
>>>> kai_tcp_server を利用する他のモジュールに
>>>> 「起動したい場合は sup の関数を使う」
>>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>>> とモジュール名を選択させるよりは
>>>> kai_tcp_server に I/F を集中させてしまった方が
>>>> 良いのではないかと考えておりますが
>>>> 如何でしょうか？
>>>>
>>>>
>>>> 案３．パッケージを使う
>>>> Scalaris くらいでしか見かけないのですが
>>>> パッケージを階層化する方法もあります。
>>>> （http://www.erlang.org/doc/man/packages.html）
>>>>
>>>> ファイルの構成は、下記を考えております。
>>>> kai_tcp_server.erl
>>>> kai_tcp_server/supervisor.erl
>>>> kai_tcp_server/monitor.erl
>>>> kai_tcp_server/acceptor.erl
>>>>
>>>> 個人的には、案２で良いかとも思いますが
>>>> パッケージを使う事で src ディレクトリ配下が
>>>> 見通しが良くなるような気もしています。
>>>> 如何でしょうか？
>>>>
>>>>
>>>> お手数ではございますが
>>>> ご意見の程、何卒よろしくお願い致します。
>>>>
>>>>
>>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>> デクリメントの処理を行ないます。
>>>>>>
>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>
>>>>> erlang:monitor/2 で登録したプロセスが
>>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>>
>>>>> Monitor の trap_exit に true を設定しておけば
>>>>> erlang:link/1 を利用しても良いのですが
>>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>>
>>>>>>> <デメリット>
>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>
>>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>
>>>>>>> gen_server である為
>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>> 何とかなりそう？
>>>>>>
>>>>>>おぉ，なるほど．
>>>>>
>>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>>> 正しく理解できていない状態で
>>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>>> 少し調査させてください。
>>>>>
>>>>> ここは、あまり神経質にならずに
>>>>> 初回の make では、warning を出す事を検討してみます。
>>>>>
>>>>> という事で、週末に案１を実装してみます。
>>>>>
>>>>>
>>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>>> 難しいですねぇ．
>>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>>
>>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>>
>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>
>>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>>
>>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>>
>>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>>
>>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>>
>>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>>> これをフックできれば一番楽なのですが
>>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>>
>>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>>
>>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>>
>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>> accept した時点で インクリメント メッセージを
>>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>>
>>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>>> 接続中リストへの Pid の追加とします。
>>>>>>> デクリメントは、その逆です。
>>>>>>>
>>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>>> デクリメントの処理を行ないます。
>>>>>>
>>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>>
>>>>>>> <デメリット>
>>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>>
>>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>>
>>>>>>> gen_server である為
>>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>>> 何とかなりそう？
>>>>>>
>>>>>> おぉ，なるほど．
>>>>>>
>>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>>
>>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>>
>>>>>>> 各 Acceptor は、Monitor へ
>>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>>> デクリメント メッセージを送ります。
>>>>>>>
>>>>>>> <デメリット>
>>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>>
>>>>>> try/catch って広く使われてるんですかねぇ．
>>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>>
>>>>>>> 以上です。
>>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>>> よろしくお願い致します。
>>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>>
>>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>>
>>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>
>>>>>>>> そうです．
>>>>>>>>
>>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>>
>>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>>> これで試してみましょうか？
>>>>>>>>
>>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>>
>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>
>>>>>>>> この方向で検討してみます．
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>
>>>>>>>>>> ご苦労様です！
>>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>>
>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>
>>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>>
>>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>>
>>>>>>>>>> 案１．
>>>>>>>>>> <方法>
>>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>>
>>>>>>>>>> <デメリット>
>>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>>
>>>>>>>>>> 案２．
>>>>>>>>>> <方法>
>>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>>
>>>>>>>>>> <デメリット>
>>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>>
>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>
>>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>>
>>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>>
>>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>>
>>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>>
>>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>>
>>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>
>>>>>>>>>>>> shino さま:
>>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>> Kai...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> cooldaemon
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>> _______________________________________________
>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>> Kai...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>>> -Strategies to boost innovation and cut costs with open source participation
>>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>>> http://p.sf.net/sfu/XcvMzF8H
>>>> _______________________________________________
>>>> Kai-devel-ja mailing list
>>>> Kai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] stats

From: Takeru I. <tak...@gm...> - 2009-02-27 22:09:47

ファイル構成のためだけのブランチはいらないんじゃないかなぁ．
kai_store のファイル構成は，kai_tcp_server が終わったら合わせて変更します．

その前に，branches/takemaru_stats/ を trunk/ にマージしておこうと思いますが，まずいことないですよね．


2009/2/26 masahito ikuta <coo...@gm...>:
>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>
> ご返信ありがとうございます。
>
> 個人的には、ファイル分割をする事で
> メンテナンス性が上がると考えておりますので
> ファイル分割を行なおうと思います。
>
> Package 対応は、全体のルールに関わる為
> もし実験的に試しで対応するのであれば
> 本件が終わった後、別途に branch を切った方が良いでしょうか？
>
> ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
> kai_store.erl
> kai_store/dets.erl
> kai_store/ets.erl
> （Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）
>
>
>
> 2009/2/26 Takeru INOUE <tak...@gm...>:
>> 井上です．
>>
>> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>>
>> 階層化の呼び出しはこんな風にするんですよね．
>>
>>  kai_tcp.sup:start()
>>
>> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>>
>> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
>> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>>
>>
>> 2009/2/26 masahito ikuta <coo...@gm...>:
>>> 皆様
>>>
>>> 幾田です。
>>> お疲れ様です。
>>>
>>> kai_tcp_server のモジュール構成について
>>> ご相談があり、メール致しました。
>>>
>>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>>> supervisor のコールバック関数 init/1 と
>>> gen_server のコールバック関数 init/1 が
>>> モジュール内で重複してしまいました。
>>>
>>> 一応、引数のパターンマッチで逃れられるのですが
>>> そろそろファイル分割の時期なのかもしれないとも考えております。
>>> 如何でしょうか？
>>>
>>>
>>> 案１．分割しない
>>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>>> 最終的なコード行数は、300 行程度になる予定である為
>>> まだ、分割しなくとも良いかもしれません。
>>>
>>>
>>> 案２．振る舞い毎にモジュールを分割
>>> 具体的には、下記のような構成を考えております。
>>>
>>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>>> kai_tcp_server_sup.erl
>>> kai_tcp_server_monitor.erl
>>> kai_tcp_server_acceptor.erl
>>>
>>> kai_tcp_server を利用する他のモジュールに
>>> 「起動したい場合は sup の関数を使う」
>>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>>> とモジュール名を選択させるよりは
>>> kai_tcp_server に I/F を集中させてしまった方が
>>> 良いのではないかと考えておりますが
>>> 如何でしょうか？
>>>
>>>
>>> 案３．パッケージを使う
>>> Scalaris くらいでしか見かけないのですが
>>> パッケージを階層化する方法もあります。
>>> （http://www.erlang.org/doc/man/packages.html）
>>>
>>> ファイルの構成は、下記を考えております。
>>> kai_tcp_server.erl
>>> kai_tcp_server/supervisor.erl
>>> kai_tcp_server/monitor.erl
>>> kai_tcp_server/acceptor.erl
>>>
>>> 個人的には、案２で良いかとも思いますが
>>> パッケージを使う事で src ディレクトリ配下が
>>> 見通しが良くなるような気もしています。
>>> 如何でしょうか？
>>>
>>>
>>> お手数ではございますが
>>> ご意見の程、何卒よろしくお願い致します。
>>>
>>>
>>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>> デクリメントの処理を行ないます。
>>>>>
>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>
>>>> erlang:monitor/2 で登録したプロセスが
>>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>>
>>>> Monitor の trap_exit に true を設定しておけば
>>>> erlang:link/1 を利用しても良いのですが
>>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>>
>>>>>> <デメリット>
>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>
>>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>
>>>>>> gen_server である為
>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>> 何とかなりそう？
>>>>>
>>>>>おぉ，なるほど．
>>>>
>>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>>> 正しく理解できていない状態で
>>>> 勢いで予想を書いてしまったので（ぉぃ）
>>>> 少し調査させてください。
>>>>
>>>> ここは、あまり神経質にならずに
>>>> 初回の make では、warning を出す事を検討してみます。
>>>>
>>>> という事で、週末に案１を実装してみます。
>>>>
>>>>
>>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>>> 難しいですねぇ．
>>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>>
>>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>>> 煮詰まったので、ご相談させてください。
>>>>>>
>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>
>>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>>
>>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>>
>>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>>
>>>>>> 案１．erlang:monitor/2 を使う
>>>>>>
>>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>>> これをフックできれば一番楽なのですが
>>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>>
>>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>>
>>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>>
>>>>>> 各 Acceptor は、Monitor へ
>>>>>> accept した時点で インクリメント メッセージを
>>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>>
>>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>>> 接続中リストへの Pid の追加とします。
>>>>>> デクリメントは、その逆です。
>>>>>>
>>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>>> デクリメントの処理を行ないます。
>>>>>
>>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>>
>>>>>> <デメリット>
>>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>>
>>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>>
>>>>>> gen_server である為
>>>>>> tarminate/2 で State を引き継げそうなので
>>>>>> 何とかなりそう？
>>>>>
>>>>> おぉ，なるほど．
>>>>>
>>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>>
>>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>>
>>>>>> 各 Acceptor は、Monitor へ
>>>>>> accept した時点で インクリメント メッセージを・・・
>>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>>> デクリメント メッセージを送ります。
>>>>>>
>>>>>> <デメリット>
>>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>>
>>>>> try/catch って広く使われてるんですかねぇ．
>>>>> そのあたりにもリスクがあったりするかもです．
>>>>>
>>>>>> 以上です。
>>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>>> よろしくお願い致します。
>>>>>> （不備のご指摘もあわせてお願い致します）
>>>>>
>>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>>
>>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>
>>>>>>> そうです．
>>>>>>>
>>>>>>>> 普通に内部でカウンタを保持して
>>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>>
>>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>>> これで試してみましょうか？
>>>>>>>
>>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>>
>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>
>>>>>>> この方向で検討してみます．
>>>>>>>
>>>>>>>
>>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>
>>>>>>>>> ご苦労様です！
>>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>>
>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>
>>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>>
>>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>>
>>>>>>>>> 案１．
>>>>>>>>> <方法>
>>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>>
>>>>>>>>> <デメリット>
>>>>>>>>> Active 時のみ対応となる。
>>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>>
>>>>>>>>> 案２．
>>>>>>>>> <方法>
>>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>>
>>>>>>>>> <デメリット>
>>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>>
>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>> どうですかねぇ?
>>>>>>>>>
>>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>>
>>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>>
>>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>>> どうですかねぇ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>>
>>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>>
>>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>>
>>>>>>>>>>> cooldaemon さま:
>>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>
>>>>>>>>>>> shino さま:
>>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>> Kai...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>> _______________________________________________
>>>>>>>> Kai-devel-ja mailing list
>>>>>>>> Kai...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> Kai-devel-ja mailing list
>>> Kai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-devel-ja] stats

From: masahito i. <coo...@gm...> - 2009-02-26 10:27:04

> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．

ご返信ありがとうございます。

個人的には、ファイル分割をする事で
メンテナンス性が上がると考えておりますので
ファイル分割を行なおうと思います。

Package 対応は、全体のルールに関わる為
もし実験的に試しで対応するのであれば
本件が終わった後、別途に branch を切った方が良いでしょうか？

ちなみに、kai_store の場合は、下記のような構成になるでしょうか。
kai_store.erl
kai_store/dets.erl
kai_store/ets.erl
（Tokyo Cabinet の Erlang Port tcerl を使うなら kai_store/tc.erl とか？）



2009/2/26 Takeru INOUE <tak...@gm...>:
> 井上です．
>
> どれも決定的な欠点はないように思うので，幾田さんが書きやすい方法でいいような気がします．
>
> 階層化の呼び出しはこんな風にするんですよね．
>
>  kai_tcp.sup:start()
>
> ちょっと読みにくいですが (慣れないだけだと思うけど)，実際上の問題はないですよね．
>
> すでに，kai_store が複数モジュールで構成されているので，そういう場合のルールを統一していった方がいいですね．
> 今後も増えることを考えると，実験的という気もするけど，階層化してった方がいいのかなぁ．
>
>
> 2009/2/26 masahito ikuta <coo...@gm...>:
>> 皆様
>>
>> 幾田です。
>> お疲れ様です。
>>
>> kai_tcp_server のモジュール構成について
>> ご相談があり、メール致しました。
>>
>> kai_tcp_server に Monitor 用の gen_server を追加しようとしたのですが
>> supervisor のコールバック関数 init/1 と
>> gen_server のコールバック関数 init/1 が
>> モジュール内で重複してしまいました。
>>
>> 一応、引数のパターンマッチで逃れられるのですが
>> そろそろファイル分割の時期なのかもしれないとも考えております。
>> 如何でしょうか？
>>
>>
>> 案１．分割しない
>> ファイルのポータビリティを重視し、分割しないのもありだと考えております。
>> 最終的なコード行数は、300 行程度になる予定である為
>> まだ、分割しなくとも良いかもしれません。
>>
>>
>> 案２．振る舞い毎にモジュールを分割
>> 具体的には、下記のような構成を考えております。
>>
>> kai_tcp_server.erl (他のモジュールから呼ばれる I/F を配置)
>> kai_tcp_server_sup.erl
>> kai_tcp_server_monitor.erl
>> kai_tcp_server_acceptor.erl
>>
>> kai_tcp_server を利用する他のモジュールに
>> 「起動したい場合は sup の関数を使う」
>> 「接続中のプロセスの個数を知りたい場合は monitor の関数を使う」
>> とモジュール名を選択させるよりは
>> kai_tcp_server に I/F を集中させてしまった方が
>> 良いのではないかと考えておりますが
>> 如何でしょうか？
>>
>>
>> 案３．パッケージを使う
>> Scalaris くらいでしか見かけないのですが
>> パッケージを階層化する方法もあります。
>> （http://www.erlang.org/doc/man/packages.html）
>>
>> ファイルの構成は、下記を考えております。
>> kai_tcp_server.erl
>> kai_tcp_server/supervisor.erl
>> kai_tcp_server/monitor.erl
>> kai_tcp_server/acceptor.erl
>>
>> 個人的には、案２で良いかとも思いますが
>> パッケージを使う事で src ディレクトリ配下が
>> 見通しが良くなるような気もしています。
>> 如何でしょうか？
>>
>>
>> お手数ではございますが
>> ご意見の程、何卒よろしくお願い致します。
>>
>>
>> 2009/2/18 masahito ikuta <coo...@gm...>:
>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>> デクリメントの処理を行ないます。
>>>>
>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>
>>> erlang:monitor/2 で登録したプロセスが
>>> 何らかの事情で停止すると、DOWN メッセージを受信します。
>>>
>>> Monitor の trap_exit に true を設定しておけば
>>> erlang:link/1 を利用しても良いのですが
>>> こう言う用途では、erlang:monitor/2 が妥当ではないかと考えました。
>>>
>>>>> <デメリット>
>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>
>>>>滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>
>>>>> gen_server である為
>>>>> tarminate/2 で State を引き継げそうなので
>>>>> 何とかなりそう？
>>>>
>>>>おぉ，なるほど．
>>>
>>> supervisor 配下の gen_server の Module:tarminate/2 の仕様を
>>> 正しく理解できていない状態で
>>> 勢いで予想を書いてしまったので（ぉぃ）
>>> 少し調査させてください。
>>>
>>> ここは、あまり神経質にならずに
>>> 初回の make では、warning を出す事を検討してみます。
>>>
>>> という事で、週末に案１を実装してみます。
>>>
>>>
>>> 2009/2/17 Takeru INOUE <tak...@gm...>:
>>>> 難しいですねぇ．
>>>> 正直言って，どちらが良いかははっきりわからないです．
>>>>
>>>> 2009/2/17 masahito ikuta <coo...@gm...>:
>>>>> 煮詰まったので、ご相談させてください。
>>>>>
>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>
>>>>> 現在、kai_tcp_server の Supervisor 配下に
>>>>> 何らかのステータス管理用プロセスを配置する事を検討中です。
>>>>>
>>>>> ※kai_state を kai_tcp_server 内で使うと、tcp_server が Kai に密結合しすぎかなぁと・・・
>>>>> この辺りも検討の余地があると思うのですが、ちょっと、それは脇に置いておきます。
>>>>
>>>> 密結合しすぎだし，利点もそれほどなさそうですね．
>>>>
>>>>> 案１．erlang:monitor/2 を使う
>>>>>
>>>>> supervidor:handle_info/2 で {'EXIT', Pid, Reason} をトラップしているので
>>>>> これをフックできれば一番楽なのですが
>>>>> 残念ながら、そう言う機構は Supervisor に用意されていないようです。
>>>>>
>>>>> そこで、Supervisor の下に (Supervisor 以外の) Acceptor 死活を監視する
>>>>> Monitor(gen_server) を配置する事を検討しております。
>>>>>
>>>>> 各 Acceptor は、起動時に Monitor へ自分の pid を送りつけ
>>>>> Monitor は、受信した pid を erlang:monitor/2 でモニタリング開始します。
>>>>>
>>>>> 各 Acceptor は、Monitor へ
>>>>> accept した時点で インクリメント メッセージを
>>>>> accept_loop を抜けた時点で デクリメント メッセージを送ります。
>>>>>
>>>>> インクリメント処理は、数値のカウントアップではなく
>>>>> 接続中リストへの Pid の追加とします。
>>>>> デクリメントは、その逆です。
>>>>>
>>>>> Monitor が {'DOWN', MonitorRef, Type, Object, Info} を受信した場合
>>>>> erlang:demonitor/1 でモニタリングを解除し
>>>>> デクリメントの処理を行ないます。
>>>>
>>>> どのようなときに DOWN が送られるんでしたっけ?
>>>>
>>>>> <デメリット>
>>>>> Monitor が落ち、Supervisor により再起動されると
>>>>> erlang:monitor/2 を、やり直す必要があります。
>>>>
>>>> 滅多にないと思うので，warning メッセージを残しておけばいいのかなぁ．
>>>>
>>>>> gen_server である為
>>>>> tarminate/2 で State を引き継げそうなので
>>>>> 何とかなりそう？
>>>>
>>>> おぉ，なるほど．
>>>>
>>>>> 案２．Mod:handle_call/3 を try catch で包む
>>>>>
>>>>> 案１と同様に、Supervisor 配下に Monitor を配置しますが
>>>>> 案１と異なり、Monitor は Acceptor の死活監視を行ないません。
>>>>>
>>>>> 各 Acceptor は、Monitor へ
>>>>> accept した時点で インクリメント メッセージを・・・
>>>>> accept_loop を抜けた際、明示的に exit/1 を実行した際、Mod:handle_call/3 で例外を catch した際に
>>>>> デクリメント メッセージを送ります。
>>>>>
>>>>> <デメリット>
>>>>> 想定外のプロセス終了が発生した場合、対処できません。
>>>>
>>>> try/catch って広く使われてるんですかねぇ．
>>>> そのあたりにもリスクがあったりするかもです．
>>>>
>>>>> 以上です。
>>>>> 案１は、実装が複雑になりそうなので、二の足を踏んでおりますが
>>>>> 案２より案１の方が erlang っぽい為、採用の方向で検討しております。
>>>>> 何か他に案があれば、ご教授頂けないでしょうか？
>>>>> よろしくお願い致します。
>>>>> （不備のご指摘もあわせてお願い致します）
>>>>
>>>> はっきりした意見はないのですが，案1 のほうに弱めの一票を入れておきます．
>>>>
>>>>> 2009/2/9 Takeru INOUE <tak...@gm...>:
>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>
>>>>>> そうです．
>>>>>>
>>>>>>> 普通に内部でカウンタを保持して
>>>>>>> Accept 毎にインクリメントしておけば良いのでは？と
>>>>>>> 先ほど、気が付きました（ｗ；
>>>>>>>
>>>>>>> 正しくデクリメントされるように作るのが難しそうですが
>>>>>>> これで試してみましょうか？
>>>>>>
>>>>>> そうそう，そこが課題っぽいんですよね．
>>>>>> エラーによる受信終了もすべてキャッチできれば，正しくデクリメントできると思います．
>>>>>> 時間があったらやってみてもらえますでしょうか．
>>>>>>
>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>
>>>>>> この方向で検討してみます．
>>>>>>
>>>>>>
>>>>>>> 2009/2/9 masahito ikuta <coo...@gm...>:
>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>
>>>>>>>> ご苦労様です！
>>>>>>>> 本業が忙しすぎて、全くコミットできておらず、申し訳ありません。
>>>>>>>>
>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>
>>>>>>>> Accept しているだけのプロセスを除いた
>>>>>>>> 今まさにリクエストを捌いている最中のプロセス数ですよね？
>>>>>>>>
>>>>>>>> あまり良い案は浮かばないのですが・・・
>>>>>>>>
>>>>>>>> 案１．
>>>>>>>> <方法>
>>>>>>>> Active で Accept した際、イベントループ内で ping メッセージを受け取ると pong を返すようにする。
>>>>>>>> ステータス取得時に、非同期で全 Accept 中のプロセスに ping を発行し、pong の数を数える。
>>>>>>>>
>>>>>>>> <デメリット>
>>>>>>>> Active 時のみ対応となる。
>>>>>>>> また、pang = タイムアウト である為、curr_connections 取得まで少し時間が掛かる。
>>>>>>>>
>>>>>>>> 案２．
>>>>>>>> <方法>
>>>>>>>> 接続の度にプロセスを作る方式に切り替える。
>>>>>>>>
>>>>>>>> <デメリット>
>>>>>>>> プロセス生成するコストを起動時に負担できない。
>>>>>>>> kai_tcp_server に大幅な修正が入る。
>>>>>>>> ステータス取得の為に、erlang らしさを捨てる事になる。
>>>>>>>>
>>>>>>>>
>>>>>>>> んー、何か正規の方法があるかもしれないので
>>>>>>>> 本家 ML に質問を出しつつ、gen_tcp のドキュメントやソースを読んでみます。
>>>>>>>>
>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>> どうですかねぇ?
>>>>>>>>
>>>>>>>> 個人的には、quorum の方が役割をイメージしやすく感じます。
>>>>>>>>
>>>>>>>>
>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>> ひとつ書き忘れました．
>>>>>>>>>
>>>>>>>>> N,R,W の設定名は，それぞれ n, r, w としています．
>>>>>>>>> しかし，stats のほうでは 3つまとめて kai_quorum という名前にしてみました．
>>>>>>>>> STAT kai_quorum 3,2,2 のようなのが返ってきます．
>>>>>>>>>
>>>>>>>>> というわけで，現時点では設定名と統計名がずれています．
>>>>>>>>> n,r,w はわかりにくい (一文字というのもよくない) ので，quorum
>>>>>>>>> にしたほうがいいのかなと思ってみたりもするのですが，今さら変更するのもどうかなと思ってみたり．
>>>>>>>>> どうですかねぇ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/2/8 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> ざっと stats を実装してみました．
>>>>>>>>>> 取得できる統計値は kai-users-ja を見てください．
>>>>>>>>>>
>>>>>>>>>> 以下は開発者向けのコメントと相談です．
>>>>>>>>>>
>>>>>>>>>> bytes (ローカルストレージのデータ量) についてです．
>>>>>>>>>> ets では正確なデータ量を得ることができませんでした．
>>>>>>>>>> これは，ets が管理しているデータ量が，大きなバイナリを含まないためです．
>>>>>>>>>> とりあえず，ets が管理してるデータ量に，Erlang VM が管理している全バイナリデータ量を加算したものを返しています．
>>>>>>>>>> かなり大きめの値が返ります．
>>>>>>>>>> また，ガベージコレクションのタイミングによっては，古い値が消されても，データ量が減らなかったりするようです．
>>>>>>>>>> 自前でデータ量を計算した方がいいですかねぇ．．
>>>>>>>>>> とはいえ，ets/dets のオーバヘッド (key のためのインデックスなど) がよくわからないので，正確な値を計算することは困難だと思っているのですが．
>>>>>>>>>>
>>>>>>>>>> cooldaemon さま:
>>>>>>>>>> curr_connections (kai_tcp_server のアクティブプロセス数) は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>
>>>>>>>>>> shino さま:
>>>>>>>>>> 二つのバージョンが返ってしまった数の累計は，どういう風に得るのが適切だと思いますでしょうか．
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>>>> _______________________________________________
>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>> Kai...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>>>>>>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>>>>>>> build responsive, highly engaging applications that combine the power of local
>>>>>>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>>>>>>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>>>>>>> _______________________________________________
>>>>>>> Kai-devel-ja mailing list
>>>>>>> Kai...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Kai-devel-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Flat | Threaded

<< < 1 2 3 4 .. 14 > >> (Page 2 of 14)

2008	Jan	Feb	Mar	Apr	May (14)	Jun (95)	Jul (94)	Aug (44)	Sep (5)	Oct (8)	Nov (14)	Dec (6)
2009	Jan	Feb (18)	Mar (19)	Apr	May (11)	Jun (8)	Jul (4)	Aug	Sep (3)	Oct	Nov	Dec
2011	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec