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

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 .. 7 8 9 10 11 .. 14 > >> (Page 9 of 14)

Re: [Kai-devel-ja] Kai 0.1.0 Released

From: Takeru I. <tak...@gm...> - 2008-07-11 15:22:12

> erlang-questions ML にも流しておきました．

早速 Joe から返事がありましたね．
"2週間のうちに key-value store が 3つも現れた" と言っています．
でも，それぞれ違う特色を持っているのが面白いかも．

6月末に Erlang eXchange という会議がロンドンであったんですねぇ．
何にも知らなかったなぁ．
スライドが公開されてないのがちょっといただけない．．

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

[Kai-devel-ja] Kai 0.1.0 Released

From: Takeru I. <tak...@gm...> - 2008-07-11 14:29:46

Kai v0.1.0 をリリースしました．
sourceforge.net からダウンロードできるようになっています．

  http://sourceforge.net/project/showfiles.php?group_id=228337

あと，Project News というのも追加したので，そのうちに head line として流れるんじゃないかと思います．

  http://sourceforge.net/news/

sourceforge.net では成熟度のようなものを示せるのですが，Pre Alpha から Alpha に格上げしました．

erlang-questions ML にも流しておきました．

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

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: masahito i. <coo...@gm...> - 2008-07-11 04:08:30

▼Erlang ML
実は、今まで Erlang ML を一切見ておりませんでした。
で、先ほど erlang-questions を subscribe しました（。。;;

アナウンスは・・・、tcp_server の edoc を書いてから行ないます。

▼CEAN など
私も手順を解っていないので、これから調べま〜す。
何方か詳しい方いらっしゃいませんか？

2008/7/11 Takeru INOUE <tak...@gm...>:
>>> これを待って，タブ文字の修正などを行いますね．
>>
>> タブの修正も、他の諸々の修正も
>> trunk 側で、バシバシ行なって頂いてかまいませんよ？
>
> trunk にコミットしました．
>
> タブ文字を修正しました．
> あと，コーディングスタイルをいくらか読みやすく改善しました．
> lists:keysearch の代わりに proplists:get_value を使うようにしました．
>
>>> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
>>
>> まずは、他のメッセージも受け取れるように修正してしまいますね。
>>
>>> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>>
>> いつ、誰が、投稿しましょうか？
>> あと、kai 本体のアナウンスが先でも良いかもしれないなーとも思ってます。
>
> そうですね．
> タブ文字の修正も終わったので，sourceforge でリリースして，ML に投げてみます．
>
> tcp_server はメインで書いた cooldaemon さんが投げるのがいいと思います．
>
>>> あぁ，ドキュメントが遅れている．．
>>
>> できる所からコツコツと（汗
>> って事で、kai_tcp_server あたりから書いてみます。
>> 英語 SKILL は娘以下なので、添削お願いしまーす（w；
>
> 誰か英語得意な人いるかな?
>
>> ところで、EDOC に対応が終わったあたりで
>> CEAN とか Erlware に対応する事も
>> 検討しませんか？
>
> はい，手順とか全然分かってないですが，広がりそうなことはやっていきましょう．
>
>
>> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>>> merge しました。
>>>
>>> お疲れ様でした．
>>> kai の改良だけでなく，tcp_server まで出来上がって大仕事だったと思います．
>>>
>>>> make test 時、一つの SUITE が終了する際に
>>>> kai_tcp_server_acceptor_N を normal で終了していない為
>>>> エラーメッセージが出ています。
>>>>
>>>> 後日修正します。
>>>
>>> これを待って，タブ文字の修正などを行いますね．
>>>
>>>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>>>> erlang ML に投げてみてもいいかも?
>>>>
>>>> erlang ML で紹介する事には賛成なのですが
>>>> 心残りが三つ、それから、提案が一つあります。
>>>>
>>>>
>>>> ▼心残り
>>>> 以下、個人的な重要度順です。
>>>>
>>>> １．テスト項目を増やす必要がある
>>>> 早々に、対応せねば。
>>>>
>>>> ２．オプションの active true 対応に見直しが必要かも？
>>>> active を true にするメリットは
>>>> receive でメッセージ待ちをする為
>>>> tcp 以外のメッセージも受信可能となる点です。
>>>> ※勉強不足で勘違いかもしれませんが
>>>>
>>>> 現在、tcp 以外のメッセージを受け取ると exit してしまうので
>>>> Mod:handle_info を評価するように修正しようかと考えておりますが
>>>> 如何なものでしょうか？
>>>>
>>>> （'EXIT' メッセージを受け取った際の処理も必要かも・・・
>>>> んー、gen 関連モジュールの source を参考にしつつ
>>>> erlang ML で意見をもらいつつ修正ってのが望ましいです）
>>>
>>> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
>>> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>>>
>>>> ３．EDOC に対応する必要がある
>>>> kai 全体に関わるのですが、edoc を採用しませんか？
>>>
>>> そうしましょう．
>>> あぁ，ドキュメントが遅れている．．
>>>
>>>> ▼提案
>>>> kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
>>>> 何となくですが、その方が他のプロジェクトでも使いやすいかと思います。
>>>
>>> 僕も tcp_server がいいと思います．
>>> p を付けるかどうかは微妙ですが，これも erlang ML に聞くのがいいのかなぁ．
>>>
>>>> ちなみに、kai というプレフィクスが消えた後も
>>>> kai のリポジトリで管理続投が良いと思います。
>>>>
>>>> ※ smerl も、元々は、単独のリポジトリで管理されていましたが
>>>>  現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）
>>>
>>> なるほど．
>>> 他のプロジェクトの参考になる部分は積極的にマネしていきましょう．
>>>
>>>
>>>> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>>>> 今日はエラーが出ませんでした．．
>>>>> なんだったのかなぁ．．
>>>>>
>>>>> 接続数が制限されるのを確認しました．
>>>>> merge していいと思います．
>>>>>
>>>>> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
>>>>> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>>>>>
>>>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>>>> erlang ML に投げてみてもいいかも?
>>>>>
>>>>>
>>>>> 2008/7/8 masahito ikuta <coo...@gm...>:
>>>>>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>>>>>> 特に動作に問題は無いように思われます。
>>>>>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>>>>>
>>>>>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>>>>                                                          11011},
>>>>>>>>>>
>>>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>>>                                                           128}]}],
>>>>>>>>>>                                                       []}
>>>>>>>>>>
>>>>>>
>>>>>>> src/kai.app.src と kai.config ですが，
>>>>>>>
>>>>>>> - src/kai.app.src はデフォルト値
>>>>>>> - kai.config はユーザ用設定ファイル
>>>>>>>
>>>>>>> というつもりでいました．
>>>>>>> erlang の一般的な使い方的にあってます?
>>>>>>
>>>>>> あってると思います。
>>>>>>
>>>>>> ただ、今回のように、設定項目を追加した場合
>>>>>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>>>>>> 修正漏れが減るのではないかと思います。
>>>>>> （テストも用意した方が良いでしょうねー）
>>>>>>
>>>>>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>>>>>> application:start(kai). したときに同じエラーが出るなぁ．
>>>>>>> こっちの環境がおかしいのかも．
>>>>>>> また明日みてみます．
>>>>>>>
>>>>>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>>> まとめられないものでしょうか？
>>>>>>>
>>>>>>> src/kai.app.src と kai.config ですが，
>>>>>>>
>>>>>>> - src/kai.app.src はデフォルト値
>>>>>>> - kai.config はユーザ用設定ファイル
>>>>>>>
>>>>>>> というつもりでいました．
>>>>>>> erlang の一般的な使い方的にあってます?
>>>>>>>
>>>>>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>>>>>
>>>>>>>
>>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>>>>>> 取り急ぎ、ご報告まで〜。
>>>>>>>>
>>>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>>>> 結構、抜けありますね…申し訳ないです。
>>>>>>>>> 今晩、修正できるところから対応していきます。
>>>>>>>>>
>>>>>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>>
>>>>>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>>>>>
>>>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>>
>>>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>>>> まとめられないものでしょうか？
>>>>>>>>>
>>>>>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> おつかれさまでした．
>>>>>>>>>>
>>>>>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>>>>>
>>>>>>>>>> ■ typo in kai.config
>>>>>>>>>>
>>>>>>>>>> kai.config に "," 抜けがありました．
>>>>>>>>>>
>>>>>>>>>> --- kai.config  (revision 372)
>>>>>>>>>> +++ kai.config  (local)
>>>>>>>>>> @@ -1,7 +1,7 @@
>>>>>>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>>>>>>     %{hostname, "localhost"},
>>>>>>>>>>     {port, 11011},
>>>>>>>>>> -    {max_connections, 30}
>>>>>>>>>> +    {max_connections, 30},
>>>>>>>>>>     {memcache_port, 11211},
>>>>>>>>>>     {memcache_max_connections, 30},
>>>>>>>>>>     {n, 3},
>>>>>>>>>>
>>>>>>>>>> ■ 起動エラー
>>>>>>>>>>
>>>>>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>>>>>
>>>>>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>>>>>> 1> application:load(kai).
>>>>>>>>>> 2> application:start(kai).
>>>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>>>>                                                          11011},
>>>>>>>>>>
>>>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>>>                                                           128}]}],
>>>>>>>>>>                                                       []}
>>>>>>>>>>
>>>>>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>>>>>    application: kai
>>>>>>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>>>>>    type: temporary
>>>>>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>>>>>
>>>>>>>>>> ■ max_connections のデフォルト値
>>>>>>>>>>
>>>>>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>>>>>
>>>>>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>>>>>
>>>>>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>>>>>
>>>>>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>>>
>>>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>>>>>
>>>>>>>>>>> ▼kai_tcp_server について
>>>>>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>>>>>> ・behaviour 化
>>>>>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>>>>>> ・{active, true} で listen 可能
>>>>>>>>>>>
>>>>>>>>>>> ▼テストについて
>>>>>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>>>>>
>>>>>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>>>>>> make に詳しい方のご助言希望。
>>>>>>>>>>>
>>>>>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>>>>>
>>>>>>>>>>> ▼現状、認識している残作業
>>>>>>>>>>> テストの Coverage を上げる。
>>>>>>>>>>>
>>>>>>>>>>> 以上です。
>>>>>>>>>>>
>>>>>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>>>>>
>>>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>>
>>>>>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>>>>>
>>>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>>
>>>>>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>>>>>
>>>>>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>>>>>    case gen_tcp:recv(
>>>>>>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>>>>>    ) of
>>>>>>>>>>>>>        {ok, Data} ->
>>>>>>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>>>                {noreply, State} ->
>>>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>>>>>>                            [
>>>>>>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>>>>>                            ],
>>>>>>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>>>>>>                    ),
>>>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>>>>>>                _Error ->
>>>>>>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>>>>>>            end;
>>>>>>>>>>>>>        {error, Reason} ->
>>>>>>>>>>>>>            exit({error, Reason})
>>>>>>>>>>>>>    end.
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>>>>>
>>>>>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>>>>>  ---
>>>>>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>>>>>
>>>>>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>>>    {
>>>>>>>>>>>>>        setopts,
>>>>>>>>>>>>>        [{packet, raw}],
>>>>>>>>>>>>>        Bytes,
>>>>>>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>>>>>    };
>>>>>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>>>>>
>>>>>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>>>>>>        ok ->
>>>>>>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>>>>>>        _Other ->
>>>>>>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>>>>>>    end.
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>>>>>
>>>>>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>>>>>> １．このまま続ける。
>>>>>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>>>
>>>>>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> 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...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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] プロセスプール [was Re: 開発の進め方]

From: Takeru I. <tak...@gm...> - 2008-07-10 15:53:14

>> これを待って，タブ文字の修正などを行いますね．
>
> タブの修正も、他の諸々の修正も
> trunk 側で、バシバシ行なって頂いてかまいませんよ？

trunk にコミットしました．

タブ文字を修正しました．
あと，コーディングスタイルをいくらか読みやすく改善しました．
lists:keysearch の代わりに proplists:get_value を使うようにしました．

>> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
>
> まずは、他のメッセージも受け取れるように修正してしまいますね。
>
>> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>
> いつ、誰が、投稿しましょうか？
> あと、kai 本体のアナウンスが先でも良いかもしれないなーとも思ってます。

そうですね．
タブ文字の修正も終わったので，sourceforge でリリースして，ML に投げてみます．

tcp_server はメインで書いた cooldaemon さんが投げるのがいいと思います．

>> あぁ，ドキュメントが遅れている．．
>
> できる所からコツコツと（汗
> って事で、kai_tcp_server あたりから書いてみます。
> 英語 SKILL は娘以下なので、添削お願いしまーす（w；

誰か英語得意な人いるかな?

> ところで、EDOC に対応が終わったあたりで
> CEAN とか Erlware に対応する事も
> 検討しませんか？

はい，手順とか全然分かってないですが，広がりそうなことはやっていきましょう．


> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>> merge しました。
>>
>> お疲れ様でした．
>> kai の改良だけでなく，tcp_server まで出来上がって大仕事だったと思います．
>>
>>> make test 時、一つの SUITE が終了する際に
>>> kai_tcp_server_acceptor_N を normal で終了していない為
>>> エラーメッセージが出ています。
>>>
>>> 後日修正します。
>>
>> これを待って，タブ文字の修正などを行いますね．
>>
>>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>>> erlang ML に投げてみてもいいかも?
>>>
>>> erlang ML で紹介する事には賛成なのですが
>>> 心残りが三つ、それから、提案が一つあります。
>>>
>>>
>>> ▼心残り
>>> 以下、個人的な重要度順です。
>>>
>>> １．テスト項目を増やす必要がある
>>> 早々に、対応せねば。
>>>
>>> ２．オプションの active true 対応に見直しが必要かも？
>>> active を true にするメリットは
>>> receive でメッセージ待ちをする為
>>> tcp 以外のメッセージも受信可能となる点です。
>>> ※勉強不足で勘違いかもしれませんが
>>>
>>> 現在、tcp 以外のメッセージを受け取ると exit してしまうので
>>> Mod:handle_info を評価するように修正しようかと考えておりますが
>>> 如何なものでしょうか？
>>>
>>> （'EXIT' メッセージを受け取った際の処理も必要かも・・・
>>> んー、gen 関連モジュールの source を参考にしつつ
>>> erlang ML で意見をもらいつつ修正ってのが望ましいです）
>>
>> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
>> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>>
>>> ３．EDOC に対応する必要がある
>>> kai 全体に関わるのですが、edoc を採用しませんか？
>>
>> そうしましょう．
>> あぁ，ドキュメントが遅れている．．
>>
>>> ▼提案
>>> kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
>>> 何となくですが、その方が他のプロジェクトでも使いやすいかと思います。
>>
>> 僕も tcp_server がいいと思います．
>> p を付けるかどうかは微妙ですが，これも erlang ML に聞くのがいいのかなぁ．
>>
>>> ちなみに、kai というプレフィクスが消えた後も
>>> kai のリポジトリで管理続投が良いと思います。
>>>
>>> ※ smerl も、元々は、単独のリポジトリで管理されていましたが
>>>  現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）
>>
>> なるほど．
>> 他のプロジェクトの参考になる部分は積極的にマネしていきましょう．
>>
>>
>>> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>>> 今日はエラーが出ませんでした．．
>>>> なんだったのかなぁ．．
>>>>
>>>> 接続数が制限されるのを確認しました．
>>>> merge していいと思います．
>>>>
>>>> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
>>>> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>>>>
>>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>>> erlang ML に投げてみてもいいかも?
>>>>
>>>>
>>>> 2008/7/8 masahito ikuta <coo...@gm...>:
>>>>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>>>>> 特に動作に問題は無いように思われます。
>>>>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>>>>
>>>>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>>>                                                          11011},
>>>>>>>>>
>>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>>                                                           128}]}],
>>>>>>>>>                                                       []}
>>>>>>>>>
>>>>>
>>>>>> src/kai.app.src と kai.config ですが，
>>>>>>
>>>>>> - src/kai.app.src はデフォルト値
>>>>>> - kai.config はユーザ用設定ファイル
>>>>>>
>>>>>> というつもりでいました．
>>>>>> erlang の一般的な使い方的にあってます?
>>>>>
>>>>> あってると思います。
>>>>>
>>>>> ただ、今回のように、設定項目を追加した場合
>>>>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>>>>> 修正漏れが減るのではないかと思います。
>>>>> （テストも用意した方が良いでしょうねー）
>>>>>
>>>>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>>>>> application:start(kai). したときに同じエラーが出るなぁ．
>>>>>> こっちの環境がおかしいのかも．
>>>>>> また明日みてみます．
>>>>>>
>>>>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>> まとめられないものでしょうか？
>>>>>>
>>>>>> src/kai.app.src と kai.config ですが，
>>>>>>
>>>>>> - src/kai.app.src はデフォルト値
>>>>>> - kai.config はユーザ用設定ファイル
>>>>>>
>>>>>> というつもりでいました．
>>>>>> erlang の一般的な使い方的にあってます?
>>>>>>
>>>>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>>>>
>>>>>>
>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>>>>> 取り急ぎ、ご報告まで〜。
>>>>>>>
>>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>>> 結構、抜けありますね…申し訳ないです。
>>>>>>>> 今晩、修正できるところから対応していきます。
>>>>>>>>
>>>>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>
>>>>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>>>>
>>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>
>>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>>> まとめられないものでしょうか？
>>>>>>>>
>>>>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>>>>> おつかれさまでした．
>>>>>>>>>
>>>>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>>>>
>>>>>>>>> ■ typo in kai.config
>>>>>>>>>
>>>>>>>>> kai.config に "," 抜けがありました．
>>>>>>>>>
>>>>>>>>> --- kai.config  (revision 372)
>>>>>>>>> +++ kai.config  (local)
>>>>>>>>> @@ -1,7 +1,7 @@
>>>>>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>>>>>     %{hostname, "localhost"},
>>>>>>>>>     {port, 11011},
>>>>>>>>> -    {max_connections, 30}
>>>>>>>>> +    {max_connections, 30},
>>>>>>>>>     {memcache_port, 11211},
>>>>>>>>>     {memcache_max_connections, 30},
>>>>>>>>>     {n, 3},
>>>>>>>>>
>>>>>>>>> ■ 起動エラー
>>>>>>>>>
>>>>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>>>>
>>>>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>>>>> 1> application:load(kai).
>>>>>>>>> 2> application:start(kai).
>>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>>>                                                          11011},
>>>>>>>>>
>>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>>                                                           128}]}],
>>>>>>>>>                                                       []}
>>>>>>>>>
>>>>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>>>>    application: kai
>>>>>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>>>>    type: temporary
>>>>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>>>>
>>>>>>>>> ■ max_connections のデフォルト値
>>>>>>>>>
>>>>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>>>>
>>>>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>>>>
>>>>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>>>>
>>>>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>>
>>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>>>>
>>>>>>>>>> ▼kai_tcp_server について
>>>>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>>>>> ・behaviour 化
>>>>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>>>>> ・{active, true} で listen 可能
>>>>>>>>>>
>>>>>>>>>> ▼テストについて
>>>>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>>>>
>>>>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>>>>> make に詳しい方のご助言希望。
>>>>>>>>>>
>>>>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>>>>
>>>>>>>>>> ▼現状、認識している残作業
>>>>>>>>>> テストの Coverage を上げる。
>>>>>>>>>>
>>>>>>>>>> 以上です。
>>>>>>>>>>
>>>>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>>>>
>>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>
>>>>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>>>>
>>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>
>>>>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>>>>
>>>>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>>>>> ---
>>>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>>>>    case gen_tcp:recv(
>>>>>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>>>>    ) of
>>>>>>>>>>>>        {ok, Data} ->
>>>>>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>>                {noreply, State} ->
>>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>>>>>                            [
>>>>>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>>>>                            ],
>>>>>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>>>>>                    ),
>>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>>>>>                _Error ->
>>>>>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>>>>>            end;
>>>>>>>>>>>>        {error, Reason} ->
>>>>>>>>>>>>            exit({error, Reason})
>>>>>>>>>>>>    end.
>>>>>>>>>>>> ---
>>>>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>>>>
>>>>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>>>>
>>>>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>>>>  ---
>>>>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>>>>
>>>>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>>    {
>>>>>>>>>>>>        setopts,
>>>>>>>>>>>>        [{packet, raw}],
>>>>>>>>>>>>        Bytes,
>>>>>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>>>>    };
>>>>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>>>>
>>>>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>>>>>        ok ->
>>>>>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>>>>>        _Other ->
>>>>>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>>>>>    end.
>>>>>>>>>>>> ---
>>>>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>>>>
>>>>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>>>>> １．このまま続ける。
>>>>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>>>>
>>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>>
>>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>>
>>>>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>>>>
>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>>>>
>>>>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 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...>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



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

Re: [Kai-devel-ja] what is pid/1 ?

From: masahito i. <coo...@gm...> - 2008-07-10 01:20:04

では、stop は残しましょう。

よくよく考えたら
stop 関数は normal exit する為に
必要かもしれないですし。

2008/7/9 Takeru INOUE <tak...@gm...>:
>>> pid を is_pid に修正する前に trunk へ merge してしまいました（汗
>>>
>>> んー・・・そもそも、application 配下に置く supervisor に stop 関数を含める必要って無いんですよね。
>>> （単独で使う場合も、あると便利という程度）
>>>
>>> ざくっと消してしまいましょうか？如何でしょう？
>>
>> ちょっとそれを判断する基礎が足りてないですが、一般的な behavior といういみでは、
>> stop が "あっても" いいんじゃないかなぁ、とおもいます。
>> kai_tcp_server の behavior としての(単体)テストのときに、もしかしたら
>> あったら便利なんじゃ?? とか。。。 # 自分がテッペンのとき
>>
>> で、is_ への修正は、「近くを触るときに、気がついたら」くらいで(僕は) 問題ないと
>> おもってます。
>
> 追加でコメントすることもありませんが，stop が邪魔になることがなければ残しましょうか．
> テストのカバレッジとかで邪魔な存在になるのかな?
>
> is_ 問題は，タブ文字を修正するときに気がついたものを直しておきます．
>
>
>> shino
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Kai-devel-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: masahito i. <coo...@gm...> - 2008-07-10 01:16:33

> これを待って，タブ文字の修正などを行いますね．

タブの修正も、他の諸々の修正も
trunk 側で、バシバシ行なって頂いてかまいませんよ？

cooldaemon_embed_tcp_server branch で
make test 時の normal exit 対応や
active true 対応等の kai_tcp_server 修正を
引き続き行う事にしようと思いますが・・・

trunk に更新があった場合は
こまめに branch に merge するので
気にしないで下さい。

> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．

まずは、他のメッセージも受け取れるように修正してしまいますね。

> こういうのは erlang ML でプロに聞いてしまうのが早そうです．

いつ、誰が、投稿しましょうか？
あと、kai 本体のアナウンスが先でも良いかもしれないなーとも思ってます。

> あぁ，ドキュメントが遅れている．．

できる所からコツコツと（汗
って事で、kai_tcp_server あたりから書いてみます。
英語 SKILL は娘以下なので、添削お願いしまーす（w；

ところで、EDOC に対応が終わったあたりで
CEAN とか Erlware に対応する事も
検討しませんか？

2008/7/9 Takeru INOUE <tak...@gm...>:
>> merge しました。
>
> お疲れ様でした．
> kai の改良だけでなく，tcp_server まで出来上がって大仕事だったと思います．
>
>> make test 時、一つの SUITE が終了する際に
>> kai_tcp_server_acceptor_N を normal で終了していない為
>> エラーメッセージが出ています。
>>
>> 後日修正します。
>
> これを待って，タブ文字の修正などを行いますね．
>
>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>> erlang ML に投げてみてもいいかも?
>>
>> erlang ML で紹介する事には賛成なのですが
>> 心残りが三つ、それから、提案が一つあります。
>>
>>
>> ▼心残り
>> 以下、個人的な重要度順です。
>>
>> １．テスト項目を増やす必要がある
>> 早々に、対応せねば。
>>
>> ２．オプションの active true 対応に見直しが必要かも？
>> active を true にするメリットは
>> receive でメッセージ待ちをする為
>> tcp 以外のメッセージも受信可能となる点です。
>> ※勉強不足で勘違いかもしれませんが
>>
>> 現在、tcp 以外のメッセージを受け取ると exit してしまうので
>> Mod:handle_info を評価するように修正しようかと考えておりますが
>> 如何なものでしょうか？
>>
>> （'EXIT' メッセージを受け取った際の処理も必要かも・・・
>> んー、gen 関連モジュールの source を参考にしつつ
>> erlang ML で意見をもらいつつ修正ってのが望ましいです）
>
> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>
>> ３．EDOC に対応する必要がある
>> kai 全体に関わるのですが、edoc を採用しませんか？
>
> そうしましょう．
> あぁ，ドキュメントが遅れている．．
>
>> ▼提案
>> kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
>> 何となくですが、その方が他のプロジェクトでも使いやすいかと思います。
>
> 僕も tcp_server がいいと思います．
> p を付けるかどうかは微妙ですが，これも erlang ML に聞くのがいいのかなぁ．
>
>> ちなみに、kai というプレフィクスが消えた後も
>> kai のリポジトリで管理続投が良いと思います。
>>
>> ※ smerl も、元々は、単独のリポジトリで管理されていましたが
>>  現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）
>
> なるほど．
> 他のプロジェクトの参考になる部分は積極的にマネしていきましょう．
>
>
>> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>> 今日はエラーが出ませんでした．．
>>> なんだったのかなぁ．．
>>>
>>> 接続数が制限されるのを確認しました．
>>> merge していいと思います．
>>>
>>> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
>>> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>>>
>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>> erlang ML に投げてみてもいいかも?
>>>
>>>
>>> 2008/7/8 masahito ikuta <coo...@gm...>:
>>>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>>>> 特に動作に問題は無いように思われます。
>>>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>>>
>>>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>>                                                          11011},
>>>>>>>>
>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>                                                           128}]}],
>>>>>>>>                                                       []}
>>>>>>>>
>>>>
>>>>> src/kai.app.src と kai.config ですが，
>>>>>
>>>>> - src/kai.app.src はデフォルト値
>>>>> - kai.config はユーザ用設定ファイル
>>>>>
>>>>> というつもりでいました．
>>>>> erlang の一般的な使い方的にあってます?
>>>>
>>>> あってると思います。
>>>>
>>>> ただ、今回のように、設定項目を追加した場合
>>>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>>>> 修正漏れが減るのではないかと思います。
>>>> （テストも用意した方が良いでしょうねー）
>>>>
>>>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>>>> application:start(kai). したときに同じエラーが出るなぁ．
>>>>> こっちの環境がおかしいのかも．
>>>>> また明日みてみます．
>>>>>
>>>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>> まとめられないものでしょうか？
>>>>>
>>>>> src/kai.app.src と kai.config ですが，
>>>>>
>>>>> - src/kai.app.src はデフォルト値
>>>>> - kai.config はユーザ用設定ファイル
>>>>>
>>>>> というつもりでいました．
>>>>> erlang の一般的な使い方的にあってます?
>>>>>
>>>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>>>
>>>>>
>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>>>> 取り急ぎ、ご報告まで〜。
>>>>>>
>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>> 結構、抜けありますね…申し訳ないです。
>>>>>>> 今晩、修正できるところから対応していきます。
>>>>>>>
>>>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>
>>>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>>>
>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>
>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>> まとめられないものでしょうか？
>>>>>>>
>>>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>>>> おつかれさまでした．
>>>>>>>>
>>>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>>>
>>>>>>>> ■ typo in kai.config
>>>>>>>>
>>>>>>>> kai.config に "," 抜けがありました．
>>>>>>>>
>>>>>>>> --- kai.config  (revision 372)
>>>>>>>> +++ kai.config  (local)
>>>>>>>> @@ -1,7 +1,7 @@
>>>>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>>>>     %{hostname, "localhost"},
>>>>>>>>     {port, 11011},
>>>>>>>> -    {max_connections, 30}
>>>>>>>> +    {max_connections, 30},
>>>>>>>>     {memcache_port, 11211},
>>>>>>>>     {memcache_max_connections, 30},
>>>>>>>>     {n, 3},
>>>>>>>>
>>>>>>>> ■ 起動エラー
>>>>>>>>
>>>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>>>
>>>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>>>> 1> application:load(kai).
>>>>>>>> 2> application:start(kai).
>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>>                                                          11011},
>>>>>>>>
>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>                                                           128}]}],
>>>>>>>>                                                       []}
>>>>>>>>
>>>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>>>    application: kai
>>>>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>>>    type: temporary
>>>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>>>
>>>>>>>> ■ max_connections のデフォルト値
>>>>>>>>
>>>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>>>
>>>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>>>
>>>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>>>
>>>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>
>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>
>>>>>>>>
>>>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>>>
>>>>>>>>> ▼kai_tcp_server について
>>>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>>>> ・behaviour 化
>>>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>>>> ・{active, true} で listen 可能
>>>>>>>>>
>>>>>>>>> ▼テストについて
>>>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>>>
>>>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>>>> make に詳しい方のご助言希望。
>>>>>>>>>
>>>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>>>
>>>>>>>>> ▼現状、認識している残作業
>>>>>>>>> テストの Coverage を上げる。
>>>>>>>>>
>>>>>>>>> 以上です。
>>>>>>>>>
>>>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>>>
>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>
>>>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>>>
>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>
>>>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>>>
>>>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>>>> ---
>>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>>>    case gen_tcp:recv(
>>>>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>>>    ) of
>>>>>>>>>>>        {ok, Data} ->
>>>>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>                {noreply, State} ->
>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>>>>                            [
>>>>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>>>                            ],
>>>>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>>>>                    ),
>>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>>>>                _Error ->
>>>>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>>>>            end;
>>>>>>>>>>>        {error, Reason} ->
>>>>>>>>>>>            exit({error, Reason})
>>>>>>>>>>>    end.
>>>>>>>>>>> ---
>>>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>>>
>>>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>>>
>>>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>>>  ---
>>>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>>>
>>>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>    {
>>>>>>>>>>>        setopts,
>>>>>>>>>>>        [{packet, raw}],
>>>>>>>>>>>        Bytes,
>>>>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>>>    };
>>>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>>>
>>>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>>>>        ok ->
>>>>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>>>>        _Other ->
>>>>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>>>>    end.
>>>>>>>>>>> ---
>>>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>>>
>>>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>>>> １．このまま続ける。
>>>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>>>
>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>
>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>
>>>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>>>
>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>>>
>>>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>>>
>>>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>>>
>>>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>>>
>>>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> 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...>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> cooldaemon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>  Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] what is pid/1 ?

From: Takeru I. <tak...@gm...> - 2008-07-09 13:29:54

>> pid を is_pid に修正する前に trunk へ merge してしまいました（汗
>>
>> んー・・・そもそも、application 配下に置く supervisor に stop 関数を含める必要って無いんですよね。
>> （単独で使う場合も、あると便利という程度）
>>
>> ざくっと消してしまいましょうか？如何でしょう？
>
> ちょっとそれを判断する基礎が足りてないですが、一般的な behavior といういみでは、
> stop が "あっても" いいんじゃないかなぁ、とおもいます。
> kai_tcp_server の behavior としての(単体)テストのときに、もしかしたら
> あったら便利なんじゃ?? とか。。。 # 自分がテッペンのとき
>
> で、is_ への修正は、「近くを触るときに、気がついたら」くらいで(僕は) 問題ないと
> おもってます。

追加でコメントすることもありませんが，stop が邪魔になることがなければ残しましょうか．
テストのカバレッジとかで邪魔な存在になるのかな?

is_ 問題は，タブ文字を修正するときに気がついたものを直しておきます．


> shino
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



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

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: Takeru I. <tak...@gm...> - 2008-07-09 13:25:38

> merge しました。

お疲れ様でした．
kai の改良だけでなく，tcp_server まで出来上がって大仕事だったと思います．

> make test 時、一つの SUITE が終了する際に
> kai_tcp_server_acceptor_N を normal で終了していない為
> エラーメッセージが出ています。
>
> 後日修正します。

これを待って，タブ文字の修正などを行いますね．

>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>> erlang ML に投げてみてもいいかも?
>
> erlang ML で紹介する事には賛成なのですが
> 心残りが三つ、それから、提案が一つあります。
>
>
> ▼心残り
> 以下、個人的な重要度順です。
>
> １．テスト項目を増やす必要がある
> 早々に、対応せねば。
>
> ２．オプションの active true 対応に見直しが必要かも？
> active を true にするメリットは
> receive でメッセージ待ちをする為
> tcp 以外のメッセージも受信可能となる点です。
> ※勉強不足で勘違いかもしれませんが
>
> 現在、tcp 以外のメッセージを受け取ると exit してしまうので
> Mod:handle_info を評価するように修正しようかと考えておりますが
> 如何なものでしょうか？
>
> （'EXIT' メッセージを受け取った際の処理も必要かも・・・
> んー、gen 関連モジュールの source を参考にしつつ
> erlang ML で意見をもらいつつ修正ってのが望ましいです）

tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
こういうのは erlang ML でプロに聞いてしまうのが早そうです．

> ３．EDOC に対応する必要がある
> kai 全体に関わるのですが、edoc を採用しませんか？

そうしましょう．
あぁ，ドキュメントが遅れている．．

> ▼提案
> kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
> 何となくですが、その方が他のプロジェクトでも使いやすいかと思います。

僕も tcp_server がいいと思います．
p を付けるかどうかは微妙ですが，これも erlang ML に聞くのがいいのかなぁ．

> ちなみに、kai というプレフィクスが消えた後も
> kai のリポジトリで管理続投が良いと思います。
>
> ※ smerl も、元々は、単独のリポジトリで管理されていましたが
>  現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）

なるほど．
他のプロジェクトの参考になる部分は積極的にマネしていきましょう．


> 2008/7/9 Takeru INOUE <tak...@gm...>:
>> 今日はエラーが出ませんでした．．
>> なんだったのかなぁ．．
>>
>> 接続数が制限されるのを確認しました．
>> merge していいと思います．
>>
>> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
>> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>>
>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>> erlang ML に投げてみてもいいかも?
>>
>>
>> 2008/7/8 masahito ikuta <coo...@gm...>:
>>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>>> 特に動作に問題は無いように思われます。
>>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>>
>>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>                                                          11011},
>>>>>>>
>>>>>>> [{number_of_virtual_nodes,
>>>>>>>                                                           128}]}],
>>>>>>>                                                       []}
>>>>>>>
>>>
>>>> src/kai.app.src と kai.config ですが，
>>>>
>>>> - src/kai.app.src はデフォルト値
>>>> - kai.config はユーザ用設定ファイル
>>>>
>>>> というつもりでいました．
>>>> erlang の一般的な使い方的にあってます?
>>>
>>> あってると思います。
>>>
>>> ただ、今回のように、設定項目を追加した場合
>>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>>> 修正漏れが減るのではないかと思います。
>>> （テストも用意した方が良いでしょうねー）
>>>
>>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>>> application:start(kai). したときに同じエラーが出るなぁ．
>>>> こっちの環境がおかしいのかも．
>>>> また明日みてみます．
>>>>
>>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>> kai.app の更新をすっかり忘れてました。
>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>> まとめられないものでしょうか？
>>>>
>>>> src/kai.app.src と kai.config ですが，
>>>>
>>>> - src/kai.app.src はデフォルト値
>>>> - kai.config はユーザ用設定ファイル
>>>>
>>>> というつもりでいました．
>>>> erlang の一般的な使い方的にあってます?
>>>>
>>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>>
>>>>
>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>>> 取り急ぎ、ご報告まで〜。
>>>>>
>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>> 結構、抜けありますね…申し訳ないです。
>>>>>> 今晩、修正できるところから対応していきます。
>>>>>>
>>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>
>>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>>
>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>
>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>> まとめられないものでしょうか？
>>>>>>
>>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>>> おつかれさまでした．
>>>>>>>
>>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>>
>>>>>>> ■ typo in kai.config
>>>>>>>
>>>>>>> kai.config に "," 抜けがありました．
>>>>>>>
>>>>>>> --- kai.config  (revision 372)
>>>>>>> +++ kai.config  (local)
>>>>>>> @@ -1,7 +1,7 @@
>>>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>>>     %{hostname, "localhost"},
>>>>>>>     {port, 11011},
>>>>>>> -    {max_connections, 30}
>>>>>>> +    {max_connections, 30},
>>>>>>>     {memcache_port, 11211},
>>>>>>>     {memcache_max_connections, 30},
>>>>>>>     {n, 3},
>>>>>>>
>>>>>>> ■ 起動エラー
>>>>>>>
>>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>>
>>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>>> 1> application:load(kai).
>>>>>>> 2> application:start(kai).
>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>                                                          11011},
>>>>>>>
>>>>>>> [{number_of_virtual_nodes,
>>>>>>>                                                           128}]}],
>>>>>>>                                                       []}
>>>>>>>
>>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>>    application: kai
>>>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>>    type: temporary
>>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>>
>>>>>>> ■ max_connections のデフォルト値
>>>>>>>
>>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>>
>>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>>
>>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>>
>>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>
>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>
>>>>>>>
>>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>>
>>>>>>>> ▼kai_tcp_server について
>>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>>> ・behaviour 化
>>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>>> ・{active, true} で listen 可能
>>>>>>>>
>>>>>>>> ▼テストについて
>>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>>
>>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>>> make に詳しい方のご助言希望。
>>>>>>>>
>>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>>
>>>>>>>> ▼現状、認識している残作業
>>>>>>>> テストの Coverage を上げる。
>>>>>>>>
>>>>>>>> 以上です。
>>>>>>>>
>>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>>
>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>
>>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>>
>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>
>>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>>
>>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>>> ---
>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>>    case gen_tcp:recv(
>>>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>>    ) of
>>>>>>>>>>        {ok, Data} ->
>>>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>                {noreply, State} ->
>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>>>                            [
>>>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>>                            ],
>>>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>>>                    ),
>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>>>                _Error ->
>>>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>>>            end;
>>>>>>>>>>        {error, Reason} ->
>>>>>>>>>>            exit({error, Reason})
>>>>>>>>>>    end.
>>>>>>>>>> ---
>>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>>
>>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>>
>>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>>  ---
>>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>>
>>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>>    {
>>>>>>>>>>        setopts,
>>>>>>>>>>        [{packet, raw}],
>>>>>>>>>>        Bytes,
>>>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>>    };
>>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>>
>>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>>>        ok ->
>>>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>>>        _Other ->
>>>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>>>    end.
>>>>>>>>>> ---
>>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>>
>>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>>> １．このまま続ける。
>>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>>
>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>
>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>
>>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>>
>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>>
>>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>>
>>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>>
>>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>>
>>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>>
>>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>>
>>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>>
>>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> 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...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



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

Re: [Kai-devel-ja] what is pid/1 ?

From: shun s. <shi...@gm...> - 2008-07-09 12:52:23

2008/7/9 masahito ikuta <coo...@gm...>:
> pid を is_pid に修正する前に trunk へ merge してしまいました（汗
>
> んー・・・そもそも、application 配下に置く supervisor に stop 関数を含める必要って無いんですよね。
> （単独で使う場合も、あると便利という程度）
>
> ざくっと消してしまいましょうか？如何でしょう？

ちょっとそれを判断する基礎が足りてないですが、一般的な behavior といういみでは、
stop が "あっても" いいんじゃないかなぁ、とおもいます。
kai_tcp_server の behavior としての(単体)テストのときに、もしかしたら
あったら便利なんじゃ?? とか。。。 # 自分がテッペンのとき

で、is_ への修正は、「近くを触るときに、気がついたら」くらいで(僕は) 問題ないと
おもってます。

shino

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: masahito i. <coo...@gm...> - 2008-07-09 12:34:00

merge しました。
取り急ぎご報告まで。

---
make test 時、一つの SUITE が終了する際に
kai_tcp_server_acceptor_N を normal で終了していない為
エラーメッセージが出ています。

後日修正します。

2008/7/9 masahito ikuta <coo...@gm...>:
>> merge していいと思います．
>
> ご確認ありがとうございました。
> 今晩あたり、本体に merge します。
>
>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>> erlang ML に投げてみてもいいかも?
>
> erlang ML で紹介する事には賛成なのですが
> 心残りが三つ、それから、提案が一つあります。
>
>
> ▼心残り
> 以下、個人的な重要度順です。
>
> １．テスト項目を増やす必要がある
> 早々に、対応せねば。
>
> ２．オプションの active true 対応に見直しが必要かも？
> active を true にするメリットは
> receive でメッセージ待ちをする為
> tcp 以外のメッセージも受信可能となる点です。
> ※勉強不足で勘違いかもしれませんが
>
> 現在、tcp 以外のメッセージを受け取ると exit してしまうので
> Mod:handle_info を評価するように修正しようかと考えておりますが
> 如何なものでしょうか？
>
> （'EXIT' メッセージを受け取った際の処理も必要かも・・・
> んー、gen 関連モジュールの source を参考にしつつ
> erlang ML で意見をもらいつつ修正ってのが望ましいです）
>
> ３．EDOC に対応する必要がある
> kai 全体に関わるのですが、edoc を採用しませんか？
>
> ▼提案
> kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
> 何となくですが、その方が他のプロジェクトでも使いやすいかと思います。
>
> ちなみに、kai というプレフィクスが消えた後も
> kai のリポジトリで管理続投が良いと思います。
>
> ※ smerl も、元々は、単独のリポジトリで管理されていましたが
>  現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）
>
> 2008/7/9 Takeru INOUE <tak...@gm...>:
>> 今日はエラーが出ませんでした．．
>> なんだったのかなぁ．．
>>
>> 接続数が制限されるのを確認しました．
>> merge していいと思います．
>>
>> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
>> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>>
>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>> erlang ML に投げてみてもいいかも?
>>
>>
>> 2008/7/8 masahito ikuta <coo...@gm...>:
>>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>>> 特に動作に問題は無いように思われます。
>>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>>
>>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>                                                          11011},
>>>>>>>
>>>>>>> [{number_of_virtual_nodes,
>>>>>>>                                                           128}]}],
>>>>>>>                                                       []}
>>>>>>>
>>>
>>>> src/kai.app.src と kai.config ですが，
>>>>
>>>> - src/kai.app.src はデフォルト値
>>>> - kai.config はユーザ用設定ファイル
>>>>
>>>> というつもりでいました．
>>>> erlang の一般的な使い方的にあってます?
>>>
>>> あってると思います。
>>>
>>> ただ、今回のように、設定項目を追加した場合
>>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>>> 修正漏れが減るのではないかと思います。
>>> （テストも用意した方が良いでしょうねー）
>>>
>>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>>> application:start(kai). したときに同じエラーが出るなぁ．
>>>> こっちの環境がおかしいのかも．
>>>> また明日みてみます．
>>>>
>>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>> kai.app の更新をすっかり忘れてました。
>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>> まとめられないものでしょうか？
>>>>
>>>> src/kai.app.src と kai.config ですが，
>>>>
>>>> - src/kai.app.src はデフォルト値
>>>> - kai.config はユーザ用設定ファイル
>>>>
>>>> というつもりでいました．
>>>> erlang の一般的な使い方的にあってます?
>>>>
>>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>>
>>>>
>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>>> 取り急ぎ、ご報告まで〜。
>>>>>
>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>> 結構、抜けありますね…申し訳ないです。
>>>>>> 今晩、修正できるところから対応していきます。
>>>>>>
>>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>
>>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>>
>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>
>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>> まとめられないものでしょうか？
>>>>>>
>>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>>> おつかれさまでした．
>>>>>>>
>>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>>
>>>>>>> ■ typo in kai.config
>>>>>>>
>>>>>>> kai.config に "," 抜けがありました．
>>>>>>>
>>>>>>> --- kai.config  (revision 372)
>>>>>>> +++ kai.config  (local)
>>>>>>> @@ -1,7 +1,7 @@
>>>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>>>     %{hostname, "localhost"},
>>>>>>>     {port, 11011},
>>>>>>> -    {max_connections, 30}
>>>>>>> +    {max_connections, 30},
>>>>>>>     {memcache_port, 11211},
>>>>>>>     {memcache_max_connections, 30},
>>>>>>>     {n, 3},
>>>>>>>
>>>>>>> ■ 起動エラー
>>>>>>>
>>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>>
>>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>>> 1> application:load(kai).
>>>>>>> 2> application:start(kai).
>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>                                                       [{{{192,168,1,225},
>>>>>>>                                                          11011},
>>>>>>>
>>>>>>> [{number_of_virtual_nodes,
>>>>>>>                                                           128}]}],
>>>>>>>                                                       []}
>>>>>>>
>>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>>    application: kai
>>>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>>    type: temporary
>>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>>
>>>>>>> ■ max_connections のデフォルト値
>>>>>>>
>>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>>
>>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>>
>>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>>
>>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>
>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>
>>>>>>>
>>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>>
>>>>>>>> ▼kai_tcp_server について
>>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>>> ・behaviour 化
>>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>>> ・{active, true} で listen 可能
>>>>>>>>
>>>>>>>> ▼テストについて
>>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>>
>>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>>> make に詳しい方のご助言希望。
>>>>>>>>
>>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>>
>>>>>>>> ▼現状、認識している残作業
>>>>>>>> テストの Coverage を上げる。
>>>>>>>>
>>>>>>>> 以上です。
>>>>>>>>
>>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>>
>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>
>>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>>
>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>
>>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>>
>>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>>> ---
>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>>    case gen_tcp:recv(
>>>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>>    ) of
>>>>>>>>>>        {ok, Data} ->
>>>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>                {noreply, State} ->
>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>>>                            [
>>>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>>                            ],
>>>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>>>                    ),
>>>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>>>                _Error ->
>>>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>>>            end;
>>>>>>>>>>        {error, Reason} ->
>>>>>>>>>>            exit({error, Reason})
>>>>>>>>>>    end.
>>>>>>>>>> ---
>>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>>
>>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>>
>>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>>  ---
>>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>>
>>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>>    {
>>>>>>>>>>        setopts,
>>>>>>>>>>        [{packet, raw}],
>>>>>>>>>>        Bytes,
>>>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>>    };
>>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>>
>>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>>>        ok ->
>>>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>>>        _Other ->
>>>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>>>    end.
>>>>>>>>>> ---
>>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>>
>>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>>> １．このまま続ける。
>>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>>
>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>
>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>
>>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>>
>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>>
>>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>>
>>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>>
>>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>>
>>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>>
>>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>>
>>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>>
>>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>>
>>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> 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...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>  Takeru INOUE <tak...@gm...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



-- 
cooldaemon

Re: [Kai-devel-ja] what is pid/1 ?

From: masahito i. <coo...@gm...> - 2008-07-09 12:27:28

pid を is_pid に修正する前に trunk へ merge してしまいました（汗

んー・・・そもそも、application 配下に置く supervisor に stop 関数を含める必要って無いんですよね。
（単独で使う場合も、あると便利という程度）

ざくっと消してしまいましょうか？如何でしょう？

2008/7/9 shun shino <shi...@gm...>:
>> 2008/7/9 masahito ikuta <coo...@gm...>:
>>>> という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
>>>> 止まってしまいました。
>>>
>>> 何を見て知ったのか記憶の彼方ですが
>>> Guard 節の中で評価する関数名のプレフィクス is_ は省略できるのです。
>>> なので、erlang:pid/1 という関数は存在しません。
>>> 解り難いですよねー。
>
> おぉー、ここで質問してよかったです。自力では絶対辿りつけなかったとおもいます。
> ありがとうございました。 m(_ _)m
>
>> http://www.erlang.org/doc/reference_manual/expressions.html#6.24
>> ここに出てました。
>>
>> あんまり英語が得意ではないので、よく解らないのですが
>> 古いから使うなって怒られているような？（汗
>>
>
> ====
> These old BIFs are retained for backwards compatibility only and
> should not be used in new code.
> ====
>
> ここですね。たしかに、後方互換性と書いてありますね f(--)
> 動作としては問題ないですし、気がついたら、 is_ 付けるように
> すればよいですかね :-)
>
> shino
>



-- 
cooldaemon

Re: [Kai-devel-ja] what is pid/1 ?

From: shun s. <shi...@gm...> - 2008-07-09 12:03:50

> 2008/7/9 masahito ikuta <coo...@gm...>:
>>> という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
>>> 止まってしまいました。
>>
>> 何を見て知ったのか記憶の彼方ですが
>> Guard 節の中で評価する関数名のプレフィクス is_ は省略できるのです。
>> なので、erlang:pid/1 という関数は存在しません。
>> 解り難いですよねー。

おぉー、ここで質問してよかったです。自力では絶対辿りつけなかったとおもいます。
ありがとうございました。 m(_ _)m

> http://www.erlang.org/doc/reference_manual/expressions.html#6.24
> ここに出てました。
>
> あんまり英語が得意ではないので、よく解らないのですが
> 古いから使うなって怒られているような？（汗
>

====
These old BIFs are retained for backwards compatibility only and
should not be used in new code.
====

ここですね。たしかに、後方互換性と書いてありますね f(--)
動作としては問題ないですし、気がついたら、 is_ 付けるように
すればよいですかね :-)

shino

Re: [Kai-devel-ja] what is pid/1 ?

From: masahito i. <coo...@gm...> - 2008-07-09 09:11:16

http://www.erlang.org/doc/reference_manual/expressions.html#6.24
ここに出てました。

あんまり英語が得意ではないので、よく解らないのですが
古いから使うなって怒られているような？（汗

2008/7/9 masahito ikuta <coo...@gm...>:
>> という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
>> 止まってしまいました。
>
> 何を見て知ったのか記憶の彼方ですが
> Guard 節の中で評価する関数名のプレフィクス is_ は省略できるのです。
>
> case {} of
>  T when tuple(T) -> is_tuple;
>   _  -> ng
> end.
>
> なので、erlang:pid/1 という関数は存在しません。
> 解り難いですよねー。
> ブログに書いておこうっと・・・。
>
> 2008/7/9 shun shino <shi...@gm...>:
>> cooldaemon さんのブランチを追いかけながら、やっと kai の勉強にてをつけはじめました。
>>
>> と、すごく初歩的な質問をひとつ m(_ _)m
>> kai_tcp_server.erl L.36 の stop/0 のなかで
>>
>> stop() ->
>>    case whereis(?MODULE) of
>>        Pid when pid(Pid) ->
>>
>> という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
>> 止まってしまいました。
>>
>> いちおう、試行錯誤としては、、、
>>
>> - ひとつ上の whereis は、 erl -man whereis なんかで探せました
>>
>> - whereis で erlang のコードを grep してみると、
>>  stdlib-1.15.2/src/gen.erl L.133 の、call/4 という関数の中で、
>>    case whereis(Name) of
>>        Pid when is_pid(Pid) ->
>>            do_call(Pid, Label, Request, Timeout);
>>  というコードがありました。
>>
>> こういう関数だよ、なり、こう調べたらいいよ、なり、なんかヒントでもお願いします m(_ _)m
>>
>> # erlang は、 otp_src_R12B-2.tar.gz から、インストールしました。
>>
>> shino
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Kai-devel-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>
>
>
>
> --
> cooldaemon
>



-- 
cooldaemon

Re: [Kai-devel-ja] what is pid/1 ?

From: masahito i. <coo...@gm...> - 2008-07-09 09:00:52

> という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
> 止まってしまいました。

何を見て知ったのか記憶の彼方ですが
Guard 節の中で評価する関数名のプレフィクス is_ は省略できるのです。

case {} of
  T when tuple(T) -> is_tuple;
   _  -> ng
end.

なので、erlang:pid/1 という関数は存在しません。
解り難いですよねー。
ブログに書いておこうっと・・・。

2008/7/9 shun shino <shi...@gm...>:
> cooldaemon さんのブランチを追いかけながら、やっと kai の勉強にてをつけはじめました。
>
> と、すごく初歩的な質問をひとつ m(_ _)m
> kai_tcp_server.erl L.36 の stop/0 のなかで
>
> stop() ->
>    case whereis(?MODULE) of
>        Pid when pid(Pid) ->
>
> という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
> 止まってしまいました。
>
> いちおう、試行錯誤としては、、、
>
> - ひとつ上の whereis は、 erl -man whereis なんかで探せました
>
> - whereis で erlang のコードを grep してみると、
>  stdlib-1.15.2/src/gen.erl L.133 の、call/4 という関数の中で、
>    case whereis(Name) of
>        Pid when is_pid(Pid) ->
>            do_call(Pid, Label, Request, Timeout);
>  というコードがありました。
>
> こういう関数だよ、なり、こう調べたらいいよ、なり、なんかヒントでもお願いします m(_ _)m
>
> # erlang は、 otp_src_R12B-2.tar.gz から、インストールしました。
>
> shino
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Kai-devel-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>



-- 
cooldaemon

[Kai-devel-ja] what is pid/1 ?

From: shun s. <shi...@gm...> - 2008-07-09 05:58:36

cooldaemon さんのブランチを追いかけながら、やっと kai の勉強にてをつけはじめました。

と、すごく初歩的な質問をひとつ m(_ _)m
kai_tcp_server.erl L.36 の stop/0 のなかで

stop() ->
    case whereis(?MODULE) of
        Pid when pid(Pid) ->

という部分があるのですが、 pid/1 を調べようとして、どこにあるかわからず
止まってしまいました。

いちおう、試行錯誤としては、、、

- ひとつ上の whereis は、 erl -man whereis なんかで探せました

- whereis で erlang のコードを grep してみると、
  stdlib-1.15.2/src/gen.erl L.133 の、call/4 という関数の中で、
    case whereis(Name) of
	Pid when is_pid(Pid) ->
	    do_call(Pid, Label, Request, Timeout);
  というコードがありました。

こういう関数だよ、なり、こう調べたらいいよ、なり、なんかヒントでもお願いします m(_ _)m

# erlang は、 otp_src_R12B-2.tar.gz から、インストールしました。

shino

Re: [Kai-devel-ja] erlang-ja in google groups

From: shun s. <shi...@gm...> - 2008-07-09 05:38:08

2008/7/9 Tsukasa Hamano <ml...@cu...>:
> こんにちは、濱野です。
>
> ご指摘ありがとう御座います。
> 文字化けの原因とエラーで終了していた原因は別だったのですが、とりあえず
> 表示は出来るようになりました。
> まだ件名が化けているのは仰る通り ISO-2022-JP で決め打ちにしているのがま

早速の対応、ありがとうございました。 m(_ _)m

Re: [Kai-devel-ja] erlang-ja in google groups

From: Tsukasa H. <ml...@cu...> - 2008-07-09 02:41:08

こんにちは、濱野です。

At Wed, 9 Jul 2008 09:37:57 +0900,
shun shino wrote:
> 
> ごめんなさい。
> ezmlm というのを初めて知ったので、分からないのですが、
> gmail を英語モードで使っているので、UTF-8/base64 になっています。
> # もしかしたら、ISO-2022-JP きめうちでなにかおかしくなったのかなぁ、と

ご指摘ありがとう御座います。
文字化けの原因とエラーで終了していた原因は別だったのですが、とりあえず
表示は出来るようになりました。
まだ件名が化けているのは仰る通り ISO-2022-JP で決め打ちにしているのがま
ずかったですね^^;文字エンコーディングを判別するよう修正しようと思います。
本文の方は、mime part のそれぞれできちんと判定しているので問題ないよう
です。

と、こんな風に ezmlm-www というビューアはマルチバイト環境での動作実績が
少ないようで、今後もおかしな挙動になる可能性がありますので gmame でのアー
カイブもあった方が良さそうですね。

> あ、 http://erlang-users.jp/ml/test/index.cgi?0:::rss ってのがありますね!
> すばらしいです!!

これも化け化けですね、本運用前には直しておきます^^;

以上、よろしくお願い致します。

At Wed, 9 Jul 2008 09:37:57 +0900,
shun shino wrote:
> 
> しのはらです。
> 
> 2008/7/9 Tsukasa Hamano <ha...@cu...>:
> tes...@er...
> >
> > ezmlm-www という、mailbox -> html ビューアのバグだったのですが、さきほ
> > ど、直りました:-)
> > http://github.com/hamano/erlang-users.jp/commit/19a9c0101dc8584c44e5d282ee663fefb11b4016
> 
> 仕事、はやいですねー!
> ぼくも登録してみましたー。
> で、gmail から投稿してみたのですが、アーカイブを見ると
> 
> te...@er...
> ====
>  Software error:
> Wide character in subroutine entry at /usr/lib/perl/5.8/Encode.pm line 166.
> ====  http://erlang-users.jp/ml/test/?0:200807
> 
> となってしまいました (T-T)
> ぼくが投稿する前にはログがちゃんと見れていたので、ぼくの仕業っぽいです。
> ごめんなさい。
> ezmlm というのを初めて知ったので、分からないのですが、
> gmail を英語モードで使っているので、UTF-8/base64 になっています。
> # もしかしたら、ISO-2022-JP きめうちでなにかおかしくなったのかなぁ、と
> 
> ==== 送っためーるのヘッダ抜粋
> Subject: =?UTF-8?B?44OG44K544OI44Oh44O844Or?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: base64
> =====
> 
> いらんことしてしまって、ほんとにスミマセン。
> 
> >> 僕は google groups == ML くらいにしか思ってないので，作っていただいた
> >> ML でいいじゃんとか思ってるのですが，どんなもんでしょう．
> 
> ML のアーカイブと共に、 RSS(Atom といったほうがいい?) feed の配信が
> あると、ちょっと中身を見てみたい(けど、サブスクライブ面倒)なときに、
> 手軽に読めていいなぁ、とおもいます。
> あ、 http://erlang-users.jp/ml/test/index.cgi?0:::rss ってのがありますね!
> すばらしいです!!
> 
> shino
-- 
Tsukasa Hamano <ha...@cu...>

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: masahito i. <coo...@gm...> - 2008-07-09 02:35:44

> merge していいと思います．

ご確認ありがとうございました。
今晩あたり、本体に merge します。

> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
> erlang ML に投げてみてもいいかも?

erlang ML で紹介する事には賛成なのですが
心残りが三つ、それから、提案が一つあります。


▼心残り
以下、個人的な重要度順です。

１．テスト項目を増やす必要がある
早々に、対応せねば。

２．オプションの active true 対応に見直しが必要かも？
active を true にするメリットは
receive でメッセージ待ちをする為
tcp 以外のメッセージも受信可能となる点です。
※勉強不足で勘違いかもしれませんが

現在、tcp 以外のメッセージを受け取ると exit してしまうので
Mod:handle_info を評価するように修正しようかと考えておりますが
如何なものでしょうか？

（'EXIT' メッセージを受け取った際の処理も必要かも・・・
　んー、gen 関連モジュールの source を参考にしつつ
　erlang ML で意見をもらいつつ修正ってのが望ましいです）

３．EDOC に対応する必要がある
kai 全体に関わるのですが、edoc を採用しませんか？

▼提案
kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
何となくですが、その方が他のプロジェクトでも使いやすいかと思います。

ちなみに、kai というプレフィクスが消えた後も
kai のリポジトリで管理続投が良いと思います。

※ smerl も、元々は、単独のリポジトリで管理されていましたが
　 現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）

2008/7/9 Takeru INOUE <tak...@gm...>:
> 今日はエラーが出ませんでした．．
> なんだったのかなぁ．．
>
> 接続数が制限されるのを確認しました．
> merge していいと思います．
>
> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>
> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
> erlang ML に投げてみてもいいかも?
>
>
> 2008/7/8 masahito ikuta <coo...@gm...>:
>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>> 特に動作に問題は無いように思われます。
>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>
>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>                                                       [{{{192,168,1,225},
>>>>>>                                                          11011},
>>>>>>
>>>>>> [{number_of_virtual_nodes,
>>>>>>                                                           128}]}],
>>>>>>                                                       []}
>>>>>>
>>
>>> src/kai.app.src と kai.config ですが，
>>>
>>> - src/kai.app.src はデフォルト値
>>> - kai.config はユーザ用設定ファイル
>>>
>>> というつもりでいました．
>>> erlang の一般的な使い方的にあってます?
>>
>> あってると思います。
>>
>> ただ、今回のように、設定項目を追加した場合
>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>> 修正漏れが減るのではないかと思います。
>> （テストも用意した方が良いでしょうねー）
>>
>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>> application:start(kai). したときに同じエラーが出るなぁ．
>>> こっちの環境がおかしいのかも．
>>> また明日みてみます．
>>>
>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>> kai.app の更新をすっかり忘れてました。
>>>> んー・・・make をうまく使って、設定を一カ所に
>>>> まとめられないものでしょうか？
>>>
>>> src/kai.app.src と kai.config ですが，
>>>
>>> - src/kai.app.src はデフォルト値
>>> - kai.config はユーザ用設定ファイル
>>>
>>> というつもりでいました．
>>> erlang の一般的な使い方的にあってます?
>>>
>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>
>>>
>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>> 取り急ぎ、ご報告まで〜。
>>>>
>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>> 結構、抜けありますね…申し訳ないです。
>>>>> 今晩、修正できるところから対応していきます。
>>>>>
>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>
>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>
>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>
>>>>> kai.app の更新をすっかり忘れてました。
>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>> まとめられないものでしょうか？
>>>>>
>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>> おつかれさまでした．
>>>>>>
>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>
>>>>>> ■ typo in kai.config
>>>>>>
>>>>>> kai.config に "," 抜けがありました．
>>>>>>
>>>>>> --- kai.config  (revision 372)
>>>>>> +++ kai.config  (local)
>>>>>> @@ -1,7 +1,7 @@
>>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>>     %{hostname, "localhost"},
>>>>>>     {port, 11011},
>>>>>> -    {max_connections, 30}
>>>>>> +    {max_connections, 30},
>>>>>>     {memcache_port, 11211},
>>>>>>     {memcache_max_connections, 30},
>>>>>>     {n, 3},
>>>>>>
>>>>>> ■ 起動エラー
>>>>>>
>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>
>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>> 1> application:load(kai).
>>>>>> 2> application:start(kai).
>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>                                                       [{{{192,168,1,225},
>>>>>>                                                          11011},
>>>>>>
>>>>>> [{number_of_virtual_nodes,
>>>>>>                                                           128}]}],
>>>>>>                                                       []}
>>>>>>
>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>    application: kai
>>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>    type: temporary
>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>
>>>>>> ■ max_connections のデフォルト値
>>>>>>
>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>
>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>
>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>
>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>
>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>
>>>>>>
>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>
>>>>>>> ▼kai_tcp_server について
>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>> ・behaviour 化
>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>> ・{active, true} で listen 可能
>>>>>>>
>>>>>>> ▼テストについて
>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>
>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>> make に詳しい方のご助言希望。
>>>>>>>
>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>
>>>>>>> ▼現状、認識している残作業
>>>>>>> テストの Coverage を上げる。
>>>>>>>
>>>>>>> 以上です。
>>>>>>>
>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>
>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>
>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>
>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>
>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>
>>>>>>>>
>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>
>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>> ---
>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>    case gen_tcp:recv(
>>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>    ) of
>>>>>>>>>        {ok, Data} ->
>>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>                {noreply, State} ->
>>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>>                            [
>>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>                            ],
>>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>>                    ),
>>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>>                _Error ->
>>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>>            end;
>>>>>>>>>        {error, Reason} ->
>>>>>>>>>            exit({error, Reason})
>>>>>>>>>    end.
>>>>>>>>> ---
>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>
>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>
>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>  ---
>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>
>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>    {
>>>>>>>>>        setopts,
>>>>>>>>>        [{packet, raw}],
>>>>>>>>>        Bytes,
>>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>    };
>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>
>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>>        ok ->
>>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>>        _Other ->
>>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>>    end.
>>>>>>>>> ---
>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>
>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>> １．このまま続ける。
>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>
>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>
>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>
>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>
>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>
>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>
>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>
>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>
>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>
>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>
>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>
>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>
>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>
>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>
>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>
>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>
>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>
>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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...>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>>  Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] erlang-ja in google groups

From: shun s. <shi...@gm...> - 2008-07-09 00:37:52

しのはらです。

2008/7/9 Tsukasa Hamano <ha...@cu...>:
tes...@er...
>
> ezmlm-www という、mailbox -> html ビューアのバグだったのですが、さきほ
> ど、直りました:-)
> http://github.com/hamano/erlang-users.jp/commit/19a9c0101dc8584c44e5d282ee663fefb11b4016

仕事、はやいですねー!
ぼくも登録してみましたー。
で、gmail から投稿してみたのですが、アーカイブを見ると

te...@er...
====
 Software error:
Wide character in subroutine entry at /usr/lib/perl/5.8/Encode.pm line 166.
====  http://erlang-users.jp/ml/test/?0:200807

となってしまいました (T-T)
ぼくが投稿する前にはログがちゃんと見れていたので、ぼくの仕業っぽいです。
ごめんなさい。
ezmlm というのを初めて知ったので、分からないのですが、
gmail を英語モードで使っているので、UTF-8/base64 になっています。
# もしかしたら、ISO-2022-JP きめうちでなにかおかしくなったのかなぁ、と

==== 送っためーるのヘッダ抜粋
Subject: =?UTF-8?B?44OG44K544OI44Oh44O844Or?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
=====

いらんことしてしまって、ほんとにスミマセン。

>> 僕は google groups == ML くらいにしか思ってないので，作っていただいた
>> ML でいいじゃんとか思ってるのですが，どんなもんでしょう．

ML のアーカイブと共に、 RSS(Atom といったほうがいい?) feed の配信が
あると、ちょっと中身を見てみたい(けど、サブスクライブ面倒)なときに、
手軽に読めていいなぁ、とおもいます。
あ、 http://erlang-users.jp/ml/test/index.cgi?0:::rss ってのがありますね!
すばらしいです!!

shino

Re: [Kai-devel-ja] erlang-ja in google groups

From: Tsukasa H. <ha...@cu...> - 2008-07-08 15:49:11

こんにちは、濱野です。

At Wed, 9 Jul 2008 00:21:16 +0900,
Takeru INOUE wrote:
> 
> test ML に登録しました．
> アーカイブを見ましたが，文字化けは直ってるっぽいですね．
> 

ezmlm-www という、mailbox -> html ビューアのバグだったのですが、さきほ
ど、直りました:-)
http://github.com/hamano/erlang-users.jp/commit/19a9c0101dc8584c44e5d282ee663fefb11b4016

> 僕は google groups == ML くらいにしか思ってないので，作っていただいた ML でいいじゃんとか思ってるのですが，どんなもんでしょう．
> 
ありがとう御座います、アドレスはどうしましょうか。

erlang-ja at erlang-users.jp
でも良いですが、このドメインだと日本語以外の ML は無さそうなので
erlang at erlang-users.jp

でも良いような気がします。

その他、おかしな所や要望など御座いましたらご意見下さいませ。
# 検索は google様におまかせしようと思っております。

> 
> 2008/7/8 Tsukasa Hamano <ml...@cu...>:
> > こんにちは、濱野です。
> >
> > At Fri, 4 Jul 2008 22:37:05 +0900,
> > Takeru INOUE wrote:
> >>
> >> とりあえず作る方向で進めましょう．
> >>
> >
> > とりあえず実験的に erlang-users.jp ドメインの ML
> > te...@er... を作ってみました。
> > 参加するには、tes...@er... にメールを送り、確認メール
> > に返信すると参加出来ます。(この ML は実験用なのでそのうち消します)
> > まだ登録の WEB インターフェイスはありませんが、用意する事も出来ます。
> >
> >> 手を抜いて，google groups でいいかなとか思ってたんですが，ちゃんと自ドメインでやったほうが立派な感じがするかなぁ．
> >> アーカイブが面倒かも．
> >
> > ML アーカイブも簡単に出来るかなと、とりあえずやってみると案の定文字化け
> > しました^^;
> > http://erlang-users.jp/ml/test/
> > でも、原因が判明したのでもう少しで直せそうです。
> >
> > At Sat, 5 Jul 2008 14:31:21 +0900,
> > shun shino wrote:
> >>
> >> ap4r のときは、rubyforge.org のアーカイブがニホンゴでコケるようになったので、
> >> mail-archive と gmane にアーカイブされるようにしました。
> >> そのときのアナウンスは↓
> >> http://article.gmane.org/gmane.comp.lang.ruby.ap4r.user.japanese/1
> >>
> >> なので、自前でアーカイブしなきゃ、ってこともないかなと。
> >> 日本語(ISO-2022-JP etc.)でもちゃんとアーカイブされてますし、
> >> google でもひっかかるらしい。
> >>
> >
> > おお-、gmane ってどんな ML でもアーカイブを置く事が出来るんですね。知り
> > ませんでした。
> > 冗長にアーカイブしておいても損はないので、こちらにも取るようにすると良
> > さそうですね。。
> >
> > とりあえず erlang-users.jp ドメインでの ML を用意してみてはみたのですが、
> > 総合的なコミュニケーションツールとして google groups を使うメリットもあ
> > るかと思いますので、皆様からのご意見を頂ければと思います。
> >
> > 以上、よろしくお願い致します。
> >
> > --
> > Tsukasa Hamano <ha...@cu...>
> >
> 
> 
> 
> -- 
>  Takeru INOUE <tak...@gm...>
> 
-- 
Tsukasa Hamano <ha...@cu...>

Re: [Kai-devel-ja] erlang-ja in google groups

From: Takeru I. <tak...@gm...> - 2008-07-08 15:21:09

test ML に登録しました．
アーカイブを見ましたが，文字化けは直ってるっぽいですね．

僕は google groups == ML くらいにしか思ってないので，作っていただいた ML でいいじゃんとか思ってるのですが，どんなもんでしょう．


2008/7/8 Tsukasa Hamano <ml...@cu...>:
> こんにちは、濱野です。
>
> At Fri, 4 Jul 2008 22:37:05 +0900,
> Takeru INOUE wrote:
>>
>> とりあえず作る方向で進めましょう．
>>
>
> とりあえず実験的に erlang-users.jp ドメインの ML
> te...@er... を作ってみました。
> 参加するには、tes...@er... にメールを送り、確認メール
> に返信すると参加出来ます。(この ML は実験用なのでそのうち消します)
> まだ登録の WEB インターフェイスはありませんが、用意する事も出来ます。
>
>> 手を抜いて，google groups でいいかなとか思ってたんですが，ちゃんと自ドメインでやったほうが立派な感じがするかなぁ．
>> アーカイブが面倒かも．
>
> ML アーカイブも簡単に出来るかなと、とりあえずやってみると案の定文字化け
> しました^^;
> http://erlang-users.jp/ml/test/
> でも、原因が判明したのでもう少しで直せそうです。
>
> At Sat, 5 Jul 2008 14:31:21 +0900,
> shun shino wrote:
>>
>> ap4r のときは、rubyforge.org のアーカイブがニホンゴでコケるようになったので、
>> mail-archive と gmane にアーカイブされるようにしました。
>> そのときのアナウンスは↓
>> http://article.gmane.org/gmane.comp.lang.ruby.ap4r.user.japanese/1
>>
>> なので、自前でアーカイブしなきゃ、ってこともないかなと。
>> 日本語(ISO-2022-JP etc.)でもちゃんとアーカイブされてますし、
>> google でもひっかかるらしい。
>>
>
> おお-、gmane ってどんな ML でもアーカイブを置く事が出来るんですね。知り
> ませんでした。
> 冗長にアーカイブしておいても損はないので、こちらにも取るようにすると良
> さそうですね。。
>
> とりあえず erlang-users.jp ドメインでの ML を用意してみてはみたのですが、
> 総合的なコミュニケーションツールとして google groups を使うメリットもあ
> るかと思いますので、皆様からのご意見を頂ければと思います。
>
> 以上、よろしくお願い致します。
>
> --
> Tsukasa Hamano <ha...@cu...>
>



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

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: Takeru I. <tak...@gm...> - 2008-07-08 15:12:22

今日はエラーが出ませんでした．．
なんだったのかなぁ．．

接続数が制限されるのを確認しました．
merge していいと思います．

コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．

kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
erlang ML に投げてみてもいいかも?


2008/7/8 masahito ikuta <coo...@gm...>:
> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
> 特に動作に問題は無いように思われます。
> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>
> ちなみに、下記メッセージは、エラーではないですよね？
>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>                                                       [{{{192,168,1,225},
>>>>>                                                          11011},
>>>>>
>>>>> [{number_of_virtual_nodes,
>>>>>                                                           128}]}],
>>>>>                                                       []}
>>>>>
>
>> src/kai.app.src と kai.config ですが，
>>
>> - src/kai.app.src はデフォルト値
>> - kai.config はユーザ用設定ファイル
>>
>> というつもりでいました．
>> erlang の一般的な使い方的にあってます?
>
> あってると思います。
>
> ただ、今回のように、設定項目を追加した場合
> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
> 修正漏れが減るのではないかと思います。
> （テストも用意した方が良いでしょうねー）
>
> 2008/7/8 Takeru INOUE <tak...@gm...>:
>> application:start(kai). したときに同じエラーが出るなぁ．
>> こっちの環境がおかしいのかも．
>> また明日みてみます．
>>
>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>> kai.app の更新をすっかり忘れてました。
>>> んー・・・make をうまく使って、設定を一カ所に
>>> まとめられないものでしょうか？
>>
>> src/kai.app.src と kai.config ですが，
>>
>> - src/kai.app.src はデフォルト値
>> - kai.config はユーザ用設定ファイル
>>
>> というつもりでいました．
>> erlang の一般的な使い方的にあってます?
>>
>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>
>>
>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>> 取り急ぎ、ご報告まで〜。
>>>
>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>> 結構、抜けありますね…申し訳ないです。
>>>> 今晩、修正できるところから対応していきます。
>>>>
>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>
>>>> とりあえず、max_connections のデフォルト値を 30
>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>
>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>
>>>> kai.app の更新をすっかり忘れてました。
>>>> んー・・・make をうまく使って、設定を一カ所に
>>>> まとめられないものでしょうか？
>>>>
>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>> おつかれさまでした．
>>>>>
>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>
>>>>> ■ typo in kai.config
>>>>>
>>>>> kai.config に "," 抜けがありました．
>>>>>
>>>>> --- kai.config  (revision 372)
>>>>> +++ kai.config  (local)
>>>>> @@ -1,7 +1,7 @@
>>>>>  [{kai, [%{logfile, "kai.log"},
>>>>>     %{hostname, "localhost"},
>>>>>     {port, 11011},
>>>>> -    {max_connections, 30}
>>>>> +    {max_connections, 30},
>>>>>     {memcache_port, 11211},
>>>>>     {memcache_max_connections, 30},
>>>>>     {n, 3},
>>>>>
>>>>> ■ 起動エラー
>>>>>
>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>
>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>> 1> application:load(kai).
>>>>> 2> application:start(kai).
>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>                                                       [{{{192,168,1,225},
>>>>>                                                          11011},
>>>>>
>>>>> [{number_of_virtual_nodes,
>>>>>                                                           128}]}],
>>>>>                                                       []}
>>>>>
>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>    application: kai
>>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>    type: temporary
>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>
>>>>> ■ max_connections のデフォルト値
>>>>>
>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>
>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>
>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>
>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>
>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>
>>>>>
>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>
>>>>>> ▼kai_tcp_server について
>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>> ・behaviour 化
>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>> ・{active, true} で listen 可能
>>>>>>
>>>>>> ▼テストについて
>>>>>> ・make test 時に ./ebin を参照
>>>>>>
>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>> make に詳しい方のご助言希望。
>>>>>>
>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>
>>>>>> ▼現状、認識している残作業
>>>>>> テストの Coverage を上げる。
>>>>>>
>>>>>> 以上です。
>>>>>>
>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>
>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>
>>>>>>> 僕も 2 が良いように思いました．
>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>
>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>
>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>
>>>>>>>
>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>
>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>> ---
>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>    case gen_tcp:recv(
>>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>    ) of
>>>>>>>>        {ok, Data} ->
>>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>                {noreply, State} ->
>>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>>                    NewOption = kai_option:new(
>>>>>>>>                            [
>>>>>>>>                                {recv_length, RecvLength},
>>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>                            ],
>>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>>                    ),
>>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>                {close, DataToSend, State} ->
>>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>>                _Error ->
>>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>>            end;
>>>>>>>>        {error, Reason} ->
>>>>>>>>            exit({error, Reason})
>>>>>>>>    end.
>>>>>>>> ---
>>>>>>>> たけまるさん版に改良を加え
>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>
>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>
>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>  ---
>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>
>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>    {
>>>>>>>>        setopts,
>>>>>>>>        [{packet, raw}],
>>>>>>>>        Bytes,
>>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>>    };
>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>
>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>>        ok ->
>>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>>        _Other ->
>>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>>    end.
>>>>>>>> ---
>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>
>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>> １．このまま続ける。
>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>
>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>
>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>
>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>
>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>
>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>
>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>
>>>>>>>>>> embed_tcp_server
>>>>>>>>>>
>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>
>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>
>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>
>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>
>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>
>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>
>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>
>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>
>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>
>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>
>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>
>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>
>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>
>>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>
>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 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...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
> cooldaemon
>



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

Re: [Kai-devel-ja] erlang-ja in google groups

From: Tsukasa H. <ml...@cu...> - 2008-07-08 13:58:14

こんにちは、濱野です。

At Fri, 4 Jul 2008 22:37:05 +0900,
Takeru INOUE wrote:
> 
> とりあえず作る方向で進めましょう．
> 

とりあえず実験的に erlang-users.jp ドメインの ML
te...@er... を作ってみました。
参加するには、tes...@er... にメールを送り、確認メール
に返信すると参加出来ます。(この ML は実験用なのでそのうち消します)
まだ登録の WEB インターフェイスはありませんが、用意する事も出来ます。

> 手を抜いて，google groups でいいかなとか思ってたんですが，ちゃんと自ドメインでやったほうが立派な感じがするかなぁ．
> アーカイブが面倒かも．

ML アーカイブも簡単に出来るかなと、とりあえずやってみると案の定文字化け
しました^^;
http://erlang-users.jp/ml/test/
でも、原因が判明したのでもう少しで直せそうです。

At Sat, 5 Jul 2008 14:31:21 +0900,
shun shino wrote:
> 
> ap4r のときは、rubyforge.org のアーカイブがニホンゴでコケるようになったので、
> mail-archive と gmane にアーカイブされるようにしました。
> そのときのアナウンスは↓
> http://article.gmane.org/gmane.comp.lang.ruby.ap4r.user.japanese/1
> 
> なので、自前でアーカイブしなきゃ、ってこともないかなと。
> 日本語(ISO-2022-JP etc.)でもちゃんとアーカイブされてますし、
> google でもひっかかるらしい。
> 

おお-、gmane ってどんな ML でもアーカイブを置く事が出来るんですね。知り
ませんでした。
冗長にアーカイブしておいても損はないので、こちらにも取るようにすると良
さそうですね。。

とりあえず erlang-users.jp ドメインでの ML を用意してみてはみたのですが、
総合的なコミュニケーションツールとして google groups を使うメリットもあ
るかと思いますので、皆様からのご意見を頂ければと思います。

以上、よろしくお願い致します。

-- 
Tsukasa Hamano <ha...@cu...>

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: masahito i. <coo...@gm...> - 2008-07-08 01:23:58

MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
特に動作に問題は無いように思われます。
※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり

ちなみに、下記メッセージは、エラーではないですよね？
>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>                                                       [{{{192,168,1,225},
>>>>                                                          11011},
>>>>
>>>> [{number_of_virtual_nodes,
>>>>                                                           128}]}],
>>>>                                                       []}
>>>>

> src/kai.app.src と kai.config ですが，
>
> - src/kai.app.src はデフォルト値
> - kai.config はユーザ用設定ファイル
>
> というつもりでいました．
> erlang の一般的な使い方的にあってます?

あってると思います。

ただ、今回のように、設定項目を追加した場合
二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
修正漏れが減るのではないかと思います。
（テストも用意した方が良いでしょうねー）

2008/7/8 Takeru INOUE <tak...@gm...>:
> application:start(kai). したときに同じエラーが出るなぁ．
> こっちの環境がおかしいのかも．
> また明日みてみます．
>
>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>> kai.app の更新をすっかり忘れてました。
>> んー・・・make をうまく使って、設定を一カ所に
>> まとめられないものでしょうか？
>
> src/kai.app.src と kai.config ですが，
>
> - src/kai.app.src はデフォルト値
> - kai.config はユーザ用設定ファイル
>
> というつもりでいました．
> erlang の一般的な使い方的にあってます?
>
> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>
>
> 2008/7/7 masahito ikuta <coo...@gm...>:
>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>> 取り急ぎ、ご報告まで〜。
>>
>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>> 結構、抜けありますね…申し訳ないです。
>>> 今晩、修正できるところから対応していきます。
>>>
>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>
>>> とりあえず、max_connections のデフォルト値を 30
>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>
>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>
>>> kai.app の更新をすっかり忘れてました。
>>> んー・・・make をうまく使って、設定を一カ所に
>>> まとめられないものでしょうか？
>>>
>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>> おつかれさまでした．
>>>>
>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>
>>>> ■ typo in kai.config
>>>>
>>>> kai.config に "," 抜けがありました．
>>>>
>>>> --- kai.config  (revision 372)
>>>> +++ kai.config  (local)
>>>> @@ -1,7 +1,7 @@
>>>>  [{kai, [%{logfile, "kai.log"},
>>>>     %{hostname, "localhost"},
>>>>     {port, 11011},
>>>> -    {max_connections, 30}
>>>> +    {max_connections, 30},
>>>>     {memcache_port, 11211},
>>>>     {memcache_max_connections, 30},
>>>>     {n, 3},
>>>>
>>>> ■ 起動エラー
>>>>
>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>
>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>> 1> application:load(kai).
>>>> 2> application:start(kai).
>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>                                                       [{{{192,168,1,225},
>>>>                                                          11011},
>>>>
>>>> [{number_of_virtual_nodes,
>>>>                                                           128}]}],
>>>>                                                       []}
>>>>
>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>    application: kai
>>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>>    type: temporary
>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>
>>>> ■ max_connections のデフォルト値
>>>>
>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>
>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>> の値を大きくしたほうがいいのかなと思います．
>>>>
>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>
>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>
>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>
>>>>
>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>
>>>>> ▼kai_tcp_server について
>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>> ・behaviour 化
>>>>> ・Mod:handle_call に Socket を渡す
>>>>> ・{active, true} で listen 可能
>>>>>
>>>>> ▼テストについて
>>>>> ・make test 時に ./ebin を参照
>>>>>
>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>> make に詳しい方のご助言希望。
>>>>>
>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>> これも、make に詳しい方のご助言希望。
>>>>>
>>>>> ▼現状、認識している残作業
>>>>> テストの Coverage を上げる。
>>>>>
>>>>> 以上です。
>>>>>
>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>
>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>
>>>>>> 僕も 2 が良いように思いました．
>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>
>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>
>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>
>>>>>>
>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>
>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>> ---
>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>    case gen_tcp:recv(
>>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>    ) of
>>>>>>>        {ok, Data} ->
>>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>>                {reply, DataToSend, State} ->
>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>                {noreply, State} ->
>>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>>                    NewOption = kai_option:new(
>>>>>>>                            [
>>>>>>>                                {recv_length, RecvLength},
>>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>>                            ],
>>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>>                    ),
>>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>                {close, DataToSend, State} ->
>>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>>                    gen_tcp:close(Socket);
>>>>>>>                _Error ->
>>>>>>>                    gen_tcp:close(Socket)
>>>>>>>            end;
>>>>>>>        {error, Reason} ->
>>>>>>>            exit({error, Reason})
>>>>>>>    end.
>>>>>>> ---
>>>>>>> たけまるさん版に改良を加え
>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>
>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>
>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>  ---
>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>
>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>    {
>>>>>>>        setopts,
>>>>>>>        [{packet, raw}],
>>>>>>>        Bytes,
>>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>>    };
>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>
>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>>        ok ->
>>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>>        _Other ->
>>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>>    end.
>>>>>>> ---
>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>
>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>> １．このまま続ける。
>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>
>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>
>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>
>>>>>>> と言う事で、意見募集中です。
>>>>>>>
>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>
>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>
>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>
>>>>>>>>> embed_tcp_server
>>>>>>>>>
>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>
>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>
>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>
>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>
>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>
>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>
>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>
>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>
>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>
>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>
>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>
>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>
>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>
>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>
>>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>
>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>
>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>
>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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...>
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
cooldaemon

Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]

From: Takeru I. <tak...@gm...> - 2008-07-07 15:48:38

application:start(kai). したときに同じエラーが出るなぁ．
こっちの環境がおかしいのかも．
また明日みてみます．

> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
> kai.app の更新をすっかり忘れてました。
> んー・・・make をうまく使って、設定を一カ所に
> まとめられないものでしょうか？

src/kai.app.src と kai.config ですが，

- src/kai.app.src はデフォルト値
- kai.config はユーザ用設定ファイル

というつもりでいました．
erlang の一般的な使い方的にあってます?

あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．


2008/7/7 masahito ikuta <coo...@gm...>:
> ご指摘頂いて箇所のみ修正した版を commit 致しました。
> 取り急ぎ、ご報告まで〜。
>
> 2008/7/7 masahito ikuta <coo...@gm...>:
>> 結構、抜けありますね…申し訳ないです。
>> 今晩、修正できるところから対応していきます。
>>
>>>N:1 (30:10 とか) くらいが妥当かなと．
>>
>> とりあえず、max_connections のデフォルト値を 30
>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>
>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>
>> kai.app の更新をすっかり忘れてました。
>> んー・・・make をうまく使って、設定を一カ所に
>> まとめられないものでしょうか？
>>
>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>> おつかれさまでした．
>>>
>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>
>>> ■ typo in kai.config
>>>
>>> kai.config に "," 抜けがありました．
>>>
>>> --- kai.config  (revision 372)
>>> +++ kai.config  (local)
>>> @@ -1,7 +1,7 @@
>>>  [{kai, [%{logfile, "kai.log"},
>>>     %{hostname, "localhost"},
>>>     {port, 11011},
>>> -    {max_connections, 30}
>>> +    {max_connections, 30},
>>>     {memcache_port, 11211},
>>>     {memcache_max_connections, 30},
>>>     {n, 3},
>>>
>>> ■ 起動エラー
>>>
>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>
>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>> 1> application:load(kai).
>>> 2> application:start(kai).
>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>                                                       [{{{192,168,1,225},
>>>                                                          11011},
>>>
>>> [{number_of_virtual_nodes,
>>>                                                           128}]}],
>>>                                                       []}
>>>
>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>    application: kai
>>>    exited: {shutdown,{kai,start,[normal,[]]}}
>>>    type: temporary
>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>
>>> ■ max_connections のデフォルト値
>>>
>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>
>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>> の値を大きくしたほうがいいのかなと思います．
>>>
>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>
>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>
>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>
>>>
>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>> 一通り実装が終わったのでご報告申し上げます。
>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>
>>>> ▼kai_tcp_server について
>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>> ・behaviour 化
>>>> ・Mod:handle_call に Socket を渡す
>>>> ・{active, true} で listen 可能
>>>>
>>>> ▼テストについて
>>>> ・make test 時に ./ebin を参照
>>>>
>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>> make に詳しい方のご助言希望。
>>>>
>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>> これも、make に詳しい方のご助言希望。
>>>>
>>>> ▼現状、認識している残作業
>>>> テストの Coverage を上げる。
>>>>
>>>> 以上です。
>>>>
>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>
>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>
>>>>> 僕も 2 が良いように思いました．
>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>
>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>> これに近い感じです。（そのままは使いません）
>>>>>
>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>
>>>>>
>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>
>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>> ---
>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>    case gen_tcp:recv(
>>>>>>        Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>    ) of
>>>>>>        {ok, Data} ->
>>>>>>            case Mod:handle_call(Data, State) of
>>>>>>                {reply, DataToSend, State} ->
>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>                {noreply, State} ->
>>>>>>                    acceptor_loop(Socket, State, Mod, Option);
>>>>>>                {setopts, SocketOptions, RecvLength, State} ->
>>>>>>                    inet:setopts(Socket, SocketOptions),
>>>>>>                    NewOption = kai_option:new(
>>>>>>                            [
>>>>>>                                {recv_length, RecvLength},
>>>>>>                                {recv_timeout, Option:get(recv_timeout)}
>>>>>>                            ],
>>>>>>                            ?DEFAULT_OPT_PROP
>>>>>>                    ),
>>>>>>                    acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>                {close, DataToSend, State} ->
>>>>>>                    gen_tcp:send(Socket, DataToSend),
>>>>>>                    gen_tcp:close(Socket);
>>>>>>                _Error ->
>>>>>>                    gen_tcp:close(Socket)
>>>>>>            end;
>>>>>>        {error, Reason} ->
>>>>>>            exit({error, Reason})
>>>>>>    end.
>>>>>> ---
>>>>>> たけまるさん版に改良を加え
>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>
>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>
>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>  ---
>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>    dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>
>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>    {
>>>>>>        setopts,
>>>>>>        [{packet, raw}],
>>>>>>        Bytes,
>>>>>>        [{packet, raw}, {state, Key, Flags}]
>>>>>>    };
>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>    {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>
>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>    Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>    case kai_coordinator:route({put, Data}) of
>>>>>>        ok ->
>>>>>>            {reply, <<"STORED\r\n">>, State};
>>>>>>        _Other ->
>>>>>>            send_error_and_close("Failed to read.", State)
>>>>>>    end.
>>>>>> ---
>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>
>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>> １．このまま続ける。
>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>
>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>
>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>
>>>>>> と言う事で、意見募集中です。
>>>>>>
>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>
>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>
>>>>>>>> 念のため、branch を作ります。
>>>>>>>>
>>>>>>>> embed_tcp_server
>>>>>>>>
>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>
>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>
>>>>>>>
>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>
>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>
>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>
>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>
>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>
>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>
>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>
>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>
>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>
>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>
>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>
>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>
>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>
>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>
>>>>>>>>>>>  たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>
>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>
>>>>>>>>>>> そういう気がします．
>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>
>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>
>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>
>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>
>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>
>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>
>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>
>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>
>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>
>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>
>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と  tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>
>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>
>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>
>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  - プロセスの生死を管理すること
>>>>>>>>>>>>>>  - 同時接続数を制限すること
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>  http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>    case length(Active) of
>>>>>>>>>>>>>>>>        N when N < Max ->                         % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>            New = start_accept(Listen, Fun),  % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが  orz）
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>  Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
> cooldaemon
>



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

Flat | Threaded

<< < 1 .. 7 8 9 10 11 .. 14 > >> (Page 9 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