kai-devel-ja Mailing List for kai
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
Menu
▾
▴
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
|
|
From: Takeru I. <tak...@gm...> - 2011-03-22 07:44:06
|
井上 (インフル) です． ご存じの方も多いと思いますが，Kai の github への移行作業が行われているようです． https://github.com/shino/kai 最新の Erlang についていけておらずプログラマとしての貢献は厳しいので，仕様レベルの課題リストを送ります． なお，以下の順番は重要性とは無関係です． また，すべてに対応する必要はなく，用途に応じて取捨選択すればよいと思います． もし Kai のコードを修正したり，使用していて問題に当たったときには参考にしてください． ■ 永続ストレージへの書き込み速度向上 現在は dets に同期書き込みを行っているため，latency が大きくなってい る．これを解決するために，ふたつの解決策がある． 1) 書き込みを別プロセスで実行し，成否を確認せずにクライアントに応答 する (書き込みの非同期実行)．この方法を使う場合，アプリケーションは 書き込まれない可能性を許容しなければならず，キャッシュに近い (外部デー タで書き込みレコードを復元できるような) 用途に向く． # ここでのレコードは，Erlang の record ではなく，DB 的な意味． 2) dets に代わり，TC などの高速ストレージを利用する．別のストレージ がインストールされていることが条件となる．オープンソースであり続ける なら，外部システムに依存しないことから，デフォルトは dets のままがい いかもしれない． ■ チェックサムの確認 現在の実装では，各レコードのチェックサムとデータ本体との一致を確認し ていないと思う． なお，Amazon では，データだけでなく，制御情報でもチェックサムを使っ ている．制御情報の integrity を確認しなかったために，S3 が長時間にわ たってダウンしたことがある． ■ レコードの書き戻し あるレコードを読んだときに，複数の異なるバージョンのレプリカがあった とする．vector clocks で最新バージョンを決定できるなら，最新バージョ ンで古いバージョンを上書きするべきである． ■ バージョン不一致の読み取り処理 現在の読み取り処理は，R 個の複製を収集し，それらの間で最新バージョン を決定し，クライアントに返す．しかし，R 個だけでは最新バージョンを決 定できないときには，残りを待ってもいいかもしれない．ただし，latency を維持するために適切なタイムアウトを設定すること． ■ 最新バージョンの決定方法 vector clocks で最新バージョンを決定できないとき，アプリケーションに よってはどれでもいいから最新バージョンをひとつに決めて欲しいこともあ るだろう．そのようなときには，ランダムに最新バージョン選択し，新しい vector clocks を付けて書き戻すのがよいかもしれない． ■ 書き込み失敗の rollback たとえば N:R:W = 3:2:2 のときに，1 台でしか書き込み処理が成功しなかっ たとする．このとき，クライアントへの応答は「書き込み失敗」になる．し かし，現在の実装では，成功した書き込みの rollback は行わない．つまり， この後に読み取りを行うと，失敗したはずの最新バージョンが返ってくる可 能性がある．これを解決するには rollback を行うべきだが，そのために は transaction が必要になり，スループットが落ちる可能性がある． ■ レコードの削除 レコードの削除は難しい．たとえば N:R:W = 3:2:2 のとき，W=2 台で削除 に成功しても，1台にレコードが残ってしまうと，以降もそのレコードを読 み取れてしまう．また，クライアントから write, delete の順にリクエス トを送っていたとしても，何らかの事情でクラスタ内で write が遅れて届 いた場合，古いデータで上書きしてしまうことになる． 解決策は，レコードを削除してしまうのではなく「削除」という内容のデー タを書き込むことである (death certificate などと呼ばれる)．この「削 除」にも，バージョン番号を与え，古いデータでの上書きを避ける．そして， 適当なタイミングで garbage collection を行う． ■ 正常終了時の永続化 ets を使っている場合でも，管理者からの指示により正常に終了できるので あれば，dets に書き出し，再起動時にそのデータを利用できるとよい． ■ 一斉終了・起動時のデータ同期遅延 クラスタ全体を一斉に終了するとき，実際にはノードによって時間差がある ので，残されたノードはデータを同期しようと (レプリカを作ろうと) 無駄 な努力をしてしまう．起動するときも，最初のほうに起動したノードはデー タを同期しようとしてしまう．一斉終了・起動は特別なコマンドとし，一定 期間データ同期を行わないようにすべきかもしれない． ■ データ同期におけるまとめ転送 現在の実装では，ノード間でデータを同期するとき (起動直後を含む)，レ コード単位でそのデータを転送している．複数レコードをまとめて転送した ほうが効率的である．ただし，長期間 lock をかけるのは避けたい． ■ Merkle tree によるデータの同期ズレチェック Merkle tree は，Amazon Dynamo に実装されている (Kai はまだ)．データ の同期ズレを少ないステップ数で発見するためのデータ構造である (同期ズ レが少なければかなり速くなると思われる)．現在は，レコードごとにひと つずつ比較しており，この負荷が高い (レゾナントで利用しているときにも 指摘されていた)． 2008-07-31 に Justin さんが Merkle tree を実装してくれた． http://code.google.com/p/distributerl/ なお，異なるレコード集合に対しても同等の木構造が作られるように工夫し なければならない．たとえば，ノード A は a b c というレコード集合を持 ち，ノード B は a c d を持つとする．これらを木構造で管理するとき，ノー ド A が ((a b) c) としているのに，ノード B が ((a c) d) としてはなら ない (レコード c は a とは異なる部分木に配置されるはずである)． # この件については，shino さんとまとまった話をしたことがある． ■ 死活監視の精度向上 現在の実装では，1回でもアクセスに失敗したノードはダウンとみなしてク ラスタから切り離す (各ノードが管理するノードリストから除去する)．多 くの場合，1回のアクセス失敗という判断基準は厳しすぎる． ダウンとみなす基準を，数回連続してアクセスできないこと，あるいは一定 期間に一度もアクセスできないことに変更したほうがよいだろう． Cassandra に倣って，より高度な Accrual Style Failure Detector http://dx.doi.org/10.1109/RELDIS.2004.1353004 を実装してもよい． また，他のノードからダウン情報を受信したとき，鵜呑みにして信じるのか， 自分でも確認するのか，確認するとしてその回数をどうするのか (対象ノー ドの負荷を抑えるために少なめにするとか) というのも検討事項である．現 在の実装では，あるノードのダウン情報が拡散し始めると，たとえ誤りであっ ても，みんなで死活確認のためにアクセスしようとして，とどめを刺してし まう可能性がある． ■ join 時のチェック quorum, bucketNum などのパラメータは，クラスタ内の全ノードで一致しな ければならない．しかし，現在の実装ではこのチェックを行っていない． join するとき，quorum, bucketNum が一致していることを確認し，一致し なければ join させないようにするべきである． ■ RPC 送信先ノード 現在の実装では，クライアントからリクエストを受信すると，consistent hash によって key (レコードID) に対応する N 台のノードを選択し，それ らにリクエストを転送する (内部 RPC)．このとき，N 台のいくつかがダウ ンしていても，代替ノードを用意しない (と思う)． Amazon Dynamo では，代替ノードを含めて必ず N 台にリクエストを転送し ている (consistent hash を再計算して N 台を決定する)．さらに，ダウン ノードはすぐ復活する可能性が高いという仮定に基づき，代替ノードの役割 は一時的と考える．このため，代替ノードはダウンノードを監視し続け，復 活すればすぐにデータを書き戻す． ■ RPC タイムアウト時の受取手不在のメッセージ RPC (kai_coordinate) でタイムアウト後に届いたメッセージには受取手が おらず，mailbox にゴミがたまるかもしれない．この掃除が自動で行われな いのであれば，対策が必要である． ■ RPC にバージョン情報を追加 将来の拡張性のために，RPC メッセージにはバージョン情報を持たせてお いたほうがよいだろう． -- Takeru INOUE |
|
From: Takeru I. <tak...@gm...> - 2009-09-13 12:52:09
|
パッチを当てようと思ったのですが，当面は R12B も動作対象に含めているので，R13B から対応している re への置き換えはいずれ行うことにします． ありがとうございました． 2009/9/8 Takeru INOUE <tak...@gm...>: > ありがとうございます． > > 気にはなっていたのですが，実害はないので放置してました． > あとでパッチを当てておきます． > > # というか，開発を進めないと．． > > Kai という名前のプロジェクトはあってもおかしくないですよね． > sourceforge.net で空いていたのが奇跡だと思います． > > 2009/9/8 UENISHI Kota <kue...@gm...>: >> kai-devel-jaの皆さん >> >> 上西です。 >> 先日のErlang分散システム勉強会ではお世話になりました（ご無沙汰しています）。 >> >> ここ最近Kaiのコードを読んだり動かしたりしているのですが、 >> R13B01ではテスト時に >> 'regexp will be obsolete in R15B' >> のようなメッセージが出て気持ち悪いのでパッチを書きました。 >> 内容としては、テストにあるregexp:match/2をre:run/2で置換しただけのものです。 >> （branches/0.4.1rcをもとに作りました） >> よかったら使ってください。 >> >> #恐縮ですが、これを作る過程で、 >> #個人的に勝手ミラーレポジトリを作りました。 >> # http://bitbucket.org/kuenishi/kai-mirror/ >> #この過程で他に 'kai' がないか調べてみたところ、 >> #Kaiという名前のプロジェクトがありました。。 >> # http://bitbucket.org/bbangert/kai/ >> >> >> -- >> UENISHI Kota from PC :D >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Kai-devel-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >> >> > > > > -- > Takeru INOUE > -- Takeru INOUE |
|
From: Takeru I. <tak...@gm...> - 2009-09-08 14:50:06
|
ありがとうございます． 気にはなっていたのですが，実害はないので放置してました． あとでパッチを当てておきます． # というか，開発を進めないと．． Kai という名前のプロジェクトはあってもおかしくないですよね． sourceforge.net で空いていたのが奇跡だと思います． 2009/9/8 UENISHI Kota <kue...@gm...>: > kai-devel-jaの皆さん > > 上西です。 > 先日のErlang分散システム勉強会ではお世話になりました（ご無沙汰しています）。 > > ここ最近Kaiのコードを読んだり動かしたりしているのですが、 > R13B01ではテスト時に > 'regexp will be obsolete in R15B' > のようなメッセージが出て気持ち悪いのでパッチを書きました。 > 内容としては、テストにあるregexp:match/2をre:run/2で置換しただけのものです。 > （branches/0.4.1rcをもとに作りました） > よかったら使ってください。 > > #恐縮ですが、これを作る過程で、 > #個人的に勝手ミラーレポジトリを作りました。 > # http://bitbucket.org/kuenishi/kai-mirror/ > #この過程で他に 'kai' がないか調べてみたところ、 > #Kaiという名前のプロジェクトがありました。。 > # http://bitbucket.org/bbangert/kai/ > > > -- > UENISHI Kota from PC :D > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Kai-devel-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-devel-ja > > -- Takeru INOUE |
|
From: UENISHI K. <kue...@gm...> - 2009-09-08 14:39:29
|
kai-devel-jaの皆さん 上西です。 先日のErlang分散システム勉強会ではお世話になりました（ご無沙汰しています）。 ここ最近Kaiのコードを読んだり動かしたりしているのですが、 R13B01ではテスト時に 'regexp will be obsolete in R15B' のようなメッセージが出て気持ち悪いのでパッチを書きました。 内容としては、テストにあるregexp:match/2をre:run/2で置換しただけのものです。 （branches/0.4.1rcをもとに作りました） よかったら使ってください。 #恐縮ですが、これを作る過程で、 #個人的に勝手ミラーレポジトリを作りました。 # http://bitbucket.org/kuenishi/kai-mirror/ #この過程で他に 'kai' がないか調べてみたところ、 #Kaiという名前のプロジェクトがありました。。 # http://bitbucket.org/bbangert/kai/ -- UENISHI Kota from PC :D |
|
From: shunichi s. <shi...@gm...> - 2009-07-21 23:15:07
|
幾田さん > cherry-pick は如何でしょうか？ おおぉ、初めて知りました。次回試してみます! しのはら 2009/7/20 masahito ikuta <coo...@gm...>: > cherry-pick は如何でしょうか？ > -- shino |
|
From: masahito i. <coo...@gm...> - 2009-07-20 08:55:24
|
cherry-pick は如何でしょうか？ 2009/7/19 shunichi shinohara <shi...@gm...>: > たけるさん > > 性能試験ありがとうございます。 > trunk にマージしました。 > > 以下、kai と関係ない、蛇足な質問で申し訳ないのですが、、、、 > git-svn をはじめて使ってみて、マージ & dcommit してみたのですが、 > svn dcommit のコミット先を変更せずに、ブランチへのコミット単位で > マージする方法をご存知の方はいらっしゃれば、教えていただけるとありがたいです。 > > 今回は、svn/git branch での複数コミットを、 svn trunk への一つのコミットに > まとめて commit してしまいました。 > 悪いわけではないのですが、kai くらいのコミット頻度であれば(そうでなくても?) > trunk のログを追いかけるだけで、細かく違いが追えたほうが良いと思っています。 > # 個々の diff の意図が追えないと、後で痛い目に会うはず > > 今回は、最初、 > git-svn merge shino_data_in_bag_local (trunk を反映したローカルブランチで) > と --no-ff を付けずにマージして、 git-svn dcommit の先がブランチ > に変わってしまい困りました。 > --no-ff でコミットがマージされることは分かったのですが、trunk へのコミットが > 一つにまとまってしまいました。 > > # 慣れないのはしんどいですが、 git インターフェイスのほうが便利なのでこっちに移行したい... > > しのはら > > 2009/7/13 Takeru INOUE <tak...@gm...>: >> 遅くなりましたが，簡単に性能試験を行いました． >> 大きな変化はないようです． >> >> というわけで，trunk/ に取り込んでもいいと思います． >> >> >> 2009/6/24 Takeru INOUE <tak...@gm...>: >>> コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)． >>> >>> ローリングアップデートは難しい (というかテストを考えると面倒...) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．． >>> dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな． >>> > > -- > shino > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Kai-devel-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-devel-ja > -- cooldaemon |
|
From: shunichi s. <shi...@gm...> - 2009-07-19 09:49:52
|
たけるさん 性能試験ありがとうございます。 trunk にマージしました。 以下、kai と関係ない、蛇足な質問で申し訳ないのですが、、、、 git-svn をはじめて使ってみて、マージ & dcommit してみたのですが、 svn dcommit のコミット先を変更せずに、ブランチへのコミット単位で マージする方法をご存知の方はいらっしゃれば、教えていただけるとありがたいです。 今回は、svn/git branch での複数コミットを、 svn trunk への一つのコミットに まとめて commit してしまいました。 悪いわけではないのですが、kai くらいのコミット頻度であれば(そうでなくても?) trunk のログを追いかけるだけで、細かく違いが追えたほうが良いと思っています。 # 個々の diff の意図が追えないと、後で痛い目に会うはず 今回は、最初、 git-svn merge shino_data_in_bag_local (trunk を反映したローカルブランチで) と --no-ff を付けずにマージして、 git-svn dcommit の先がブランチ に変わってしまい困りました。 --no-ff でコミットがマージされることは分かったのですが、trunk へのコミットが 一つにまとまってしまいました。 # 慣れないのはしんどいですが、 git インターフェイスのほうが便利なのでこっちに移行したい... しのはら 2009/7/13 Takeru INOUE <tak...@gm...>: > 遅くなりましたが，簡単に性能試験を行いました． > 大きな変化はないようです． > > というわけで，trunk/ に取り込んでもいいと思います． > > > 2009/6/24 Takeru INOUE <tak...@gm...>: >> コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)． >> >> ローリングアップデートは難しい (というかテストを考えると面倒…) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．． >> dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな． >> -- shino |
|
From: Takeru I. <tak...@gm...> - 2009-07-13 13:55:11
|
遅くなりましたが，簡単に性能試験を行いました． 大きな変化はないようです． というわけで，trunk/ に取り込んでもいいと思います． 2009/6/24 Takeru INOUE <tak...@gm...>: > コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)． > > ローリングアップデートは難しい (というかテストを考えると面倒…) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．． > dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな． > > > 2009/6/23 shunichi shinohara <shi...@gm...>: >> kai-devel-ja のみなさん >> >> しのはらです。 >> 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。 >> 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって >> detach してやってみました (o^<^)o >> >> 基本的な修正は以下 3 点です >> 1. kai_store_(ets|dets) を set から bag へ変更 >> 2. kai_store の get を data から [data] を返すように変更 >> 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更 >> >> 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync >> あたりまでちょこちょこと修正を入れました。 >> memcached 層での修正はありません。 >> % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m >> >> 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、 >> 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る >> ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T) >> >> 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、 >> 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか? >> という点があるとおもいます。 >> 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような >> バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。 >> >> ここは運用している方のご意見を是非!欲しいところです。 >> >> 以上、ご意見、コメントおまちしています。 >> >> -- >> shino >> >> ------------------------------------------------------------------------------ >> Are you an open source citizen? Join us for the Open Source Bridge conference! >> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. >> Need another reason to go? 24-hour hacker lounge. Register today! >> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >> _______________________________________________ >> Kai-devel-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >> > > > > -- > Takeru INOUE > -- Takeru INOUE |
|
From: shunichi s. <shi...@gm...> - 2009-06-30 14:06:09
|
しのはらです。 2009/6/24 Tomoya Hashimoto <tom...@gm...>: > 後方互換が保てない場合のアップデートを考えてみました。 > > 運用中なのでサービスを停止せずにアップデートできるのが望ましいです。たとえば、 > ノードを１台毎に止めてアップデートできれば全体としては停止しないのでいいかと思います。 > > いったん全てのノードを止めてアップデートして、それから起動する方法もあるかと思います。 > 手順が複雑でなく、許容できそうな停止時間に収まればこれもありかと思います。 例えば、モジュールの入れ替えだけであれば、全ノード停止、という選択肢も (まぁ)許容できる、となりそうですね。とても参考になります :-) 変更をうまく分離すれば、プロトコル変更部分だけを先に全ノード停止で行って、 その後に dets ファイルの変換をノード毎に行う、という方法が可能かと思いました。 今後のことをかんがえると、プロトコル的に非互換になる場合もあるとおもうので、 複数バージョンが共存できるようなプロトコル実装を考えておきたいですね。 そうすれば、試験的に一部のノードだけアップデートして、様子を見る、という ことができるので、自分だったら嬉しいです。 > 事実上不可能と思われるアップデート方法は、すべてのオブジェクトをgetしてどこかに取っておいて、 > すべてをsetして元に戻す方法です。すべてのオブジェクトを知る方法がなかったりします。 たしかに、KVS では一般に難しいですよね。インデックスみたいなものはないので... -- shino |
|
From: Tomoya H. <tom...@gm...> - 2009-06-24 07:30:42
|
橋本です。 後方互換が保てない場合のアップデートを考えてみました。 運用中なのでサービスを停止せずにアップデートできるのが望ましいです。たとえば、ノードを１台毎に止めてアップデートできれば全体としては停止しないのでいいかと思います。 いったん全てのノードを止めてアップデートして、それから起動する方法もあるかと思います。手順が複雑でなく、許容できそうな停止時間に収まればこれもありかと思います。 事実上不可能と思われるアップデート方法は、すべてのオブジェクトをgetしてどこかに取っておいて、すべてをsetして元に戻す方法です。すべてのオブジェクトを知る方法がなかったりします。 こんなところです。 2009/06/23 16:40 に shunichi shinohara<shi...@gm...> さんは書きました: > kai-devel-ja のみなさん > > しのはらです。 > 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。 > 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって > detach してやってみました (o^<^)o > > 基本的な修正は以下 3 点です > 1. kai_store_(ets|dets) を set から bag へ変更 > 2. kai_store の get を data から [data] を返すように変更 > 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更 > > 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync > あたりまでちょこちょこと修正を入れました。 > memcached 層での修正はありません。 > % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m > > 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、 > 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る > ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T) > > 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、 > 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか? > という点があるとおもいます。 > 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような > バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。 > > ここは運用している方のご意見を是非!欲しいところです。 > > 以上、ご意見、コメントおまちしています。 > > -- > shino > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Kai-devel-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-devel-ja > |
|
From: Takeru I. <tak...@gm...> - 2009-06-24 01:28:34
|
コミットログをざっと眺めて，テストが通ることを確認しました (R12, R13 とも)． ローリングアップデートは難しい (というかテストを考えると面倒…) なので，バージョン0.x のうちは見送りたいなぁと思ってるのですが．． dets の変換スクリプトを用意するくらいが簡単かなと思ってるのだけど，運用してる方のご意見待ちかな． 2009/6/23 shunichi shinohara <shi...@gm...>: > kai-devel-ja のみなさん > > しのはらです。 > 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。 > 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって > detach してやってみました (o^<^)o > > 基本的な修正は以下 3 点です > 1. kai_store_(ets|dets) を set から bag へ変更 > 2. kai_store の get を data から [data] を返すように変更 > 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更 > > 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync > あたりまでちょこちょこと修正を入れました。 > memcached 層での修正はありません。 > % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m > > 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、 > 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る > ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T) > > 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、 > 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか? > という点があるとおもいます。 > 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような > バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。 > > ここは運用している方のご意見を是非!欲しいところです。 > > 以上、ご意見、コメントおまちしています。 > > -- > shino > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Kai-devel-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-devel-ja > -- Takeru INOUE |
|
From: shunichi s. <shi...@gm...> - 2009-06-23 07:41:28
|
kai-devel-ja のみなさん しのはらです。 単一ノードで複数バージョンを格納するように kai_store 層を変更してみました。 幾田さんの gihyo.jp の解説がとってもすばらしいので start_kai.sh とか早速ぱくって detach してやってみました (o^<^)o 基本的な修正は以下 3 点です 1. kai_store_(ets|dets) を set から bag へ変更 2. kai_store の get を data から [data] を返すように変更 3. kai_store の put を、バージョン衝突が起きても ok を返すよう変更 2. のインターフェイス変更にともない、上に向かって kai_coordinator/kai_sync あたりまでちょこちょこと修正を入れました。 memcached 層での修正はありません。 % たけるさんのテストケースリファクタ&強化のおかげで安心して作業できました m(_ _)m 1. に伴う性能低下をちょっと気にしていたのですが、kai_store_SUITE の perf で見たところ、 大きな変化はないようです。が、心配なのでもしちゃんとしたクラスタ環境での測定が出来る ようでしたら、どなたかよろしくお願いします。 # 他力本願ですんません (T-T) 実装以外の問題として、dets ファイルと、 kai_store:get の 2 つの部分で、 後方互換性を保たないようになっているので、バージョンアップのパスをどうするか? という点があるとおもいます。 例えば、クラスタ内のノードにたいして、ローリングアップデートが出来るような バージョンアップ方法が必要であれば、それをちゃんとかんがえなくてはいけません。 ここは運用している方のご意見を是非!欲しいところです。 以上、ご意見、コメントおまちしています。 -- shino |
|
From: Takeru I. <tak...@gm...> - 2009-06-03 14:24:06
|
一通り，リファクタリングが終わりました．
といっても，主にやったことはリファクタリングっぽくないのですが．．
・テストの追加・修正
・設定の変更・追加
- n,r,w → quorum
- number_of_buckets → buckets
- number_of_virtual_nodes → virtual_nodes
- number_of_tables → dets_tables
- sync_interval (データ同期間隔)
- membership_interval (メンバシップ同期間隔)
・kai_config へのアクセスを起動時に限定
- 各モジュールは必要な設定を起動時にコピー
- 第二回 erlang 勉強会で言っていた問題の解決
・戻り値が単一種の関数は，戻り値のタグを {XXX, ...} から {ok, ...} に変更
・などなど
問題なさそうなら，そのうちに trunk/ に merge しておきます．
この先は，
・dets 書き込みの高速化
・データ同期の高速化
・ノード追加の簡易化 (check_node はわかりにくいので)
・複数バージョン扱いの修正
・などなど
の予定です (順不同)．
2009/6/3 Takeru INOUE <tak...@gm...>:
> 2009/6/1 masahito ikuta <coo...@gm...>:
>>>> net_kernel:start/1, slave:start/3 を使うと
>>>> カバレッジを管理するノードがモジュールをロードしないからだと思います。
>>>>
>>>> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・
>>>> 本家 ML で聞いた方が良いかもしれません。
>>
>> よくよく考えてみると、テスト対象のモジュールは、カレントノードにロードし
>> ノード間通信の相手側だけ、別ノードでロードさせるのが
>> あるべき姿のような気がしますが、如何でしょうか？
>
> そうだと思いますが，以下の二つの理由でいまのようなテスト実装になりました．
>
> ・カレントノードにロードしたら，kai_rpc で接続エラーになった (何かを間違っていたのかもしれないけど)
> ・kai_sync のように，対になって動作するモジュールの場合 (A, B 二種類の処理ルーチンがやりとりしながら動作するということ)，A
> をカレントノードにロードするテストと，B をロードするテストを，別々に書かなければならない．
>
> ひとつめが解決したら直すかなぁ．
>
>> ちなみに、ermlia のノード間通信のテストは、mock を作りまくって対応していましたが
>> 無駄に Module のメタ操作をしていた為、カバレッジが初期化されてしまいました（w；
>
> それほど Erlang のことをわかってないので，メタ操作をするのはちょっと怖いなぁ．
>
>>>>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ．
>>>
>>> こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)．
>>
>> 私の好みは、number_of_XXX ですが
>> XXX の方が一般的（根拠なし）な気もしています。
>> 一般的な方で良いと思います。
>
> もうちょっと考えてみますね．
>
>
>> 2009/5/31 Takeru INOUE <tak...@gm...>:
>>>>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ?
>>>>
>>>> net_kernel:start/1, slave:start/3 を使うと
>>>> カバレッジを管理するノードがモジュールをロードしないからだと思います。
>>>>
>>>> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・
>>>> 本家 ML で聞いた方が良いかもしれません。
>>>>
>>>> むー、test_server を使えば回避できるのかなー？
>>>
>>> そうなのかぁ．
>>>
>>> # ML に尋ねるのは，せめて test_server を試してからだよなぁ．とか言ってると，どんどん後回しになる．．
>>>
>>>>> n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました．
>>>>
>>>> number_of_tables は、ets には関係ないので、その名前が良いと思います。
>>>
>>> ではこの線でいきます．
>>>
>>>>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ．
>>>
>>> こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)．
>>>
>>>>> rpc_max_processes, memcache_max_processes, max_connections
>>>>> のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)．
>>>>> 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)．
>>>>>
>>>>> quorum 条件のチェックを追加しました．
>>>>> R+W > N と W > N/2 を満たさないときはエラーになります．
>>>>>
>>>>>
>>>>> 2009/5/28 Takeru INOUE <tak...@gm...>:
>>>>>> 先ほど，test/ を大幅に追加・修正してコミットしました．
>>>>>> 時間のある方は試して，問題があったら連絡しくださると助かります．
>>>>>>
>>>>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ?
>>>>>>
>>>>>> なお，src/ はほとんど変更していません．
>>>>>> kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです．
>>>>>>
>>>>>>
>>>>>> 2009/5/23 Takeru INOUE <tak...@gm...>:
>>>>>>> 2009/5/23 masahito ikuta <coo...@gm...>:
>>>>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．
>>>>>>>>
>>>>>>>> 非同期にすると、信頼性が落ちそうなので
>>>>>>>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが
>>>>>>>> 如何でしょうか？
>>>>>>>
>>>>>>> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね．
>>>>>>> あぁ，設定項目が増えていく．．
>>>>>>> 苦情が来てからにしようかなぁ．．
>>>>>>>
>>>>>>>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが
>>>>>>>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？
>>>>>>>> 後で、検証しないと・・・。
>>>>>>>
>>>>>>> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．．
>>>>>>> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ．
>>>>>>>
>>>>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．
>>>>>>>>
>>>>>>>> バージョン番号が 1.0 に到達していないので
>>>>>>>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。
>>>>>>>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。
>>>>>>>
>>>>>>> 必要な修正なので，いずれはやります．
>>>>>>>
>>>>>>>> 2009/5/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>> コードの整理やテストの充実のために，リファクタリングしようと思っています．
>>>>>>>>> そのための branch を作りました．
>>>>>>>>>
>>>>>>>>> branches/takemaru_refactoring/
>>>>>>>>>
>>>>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．
>>>>>>>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので．
>>>>>>>>>
>>>>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．
>>>>>>>>> 並行して考えていきます．
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Takeru INOUE
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>>>>>>>> is a gathering of tech-side developers & brand creativity professionals. Meet
>>>>>>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>>>>>>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>>>>>>>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>>>>>>>>> _______________________________________________
>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>> Kai...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Takeru INOUE
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Takeru INOUE
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Takeru INOUE
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> Takeru INOUE
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
> Takeru INOUE
>
--
Takeru INOUE
|
|
From: Takeru I. <tak...@gm...> - 2009-06-03 14:05:07
|
互換性に関する情報を書き忘れました．
tags/0.4.0/ と branches/takemaru_refactoring/ の互換性は以下のようになっています．
・設定ファイルは後方互換性あり (warning は出る)
・Kai ノード間の RPC に互換性がないため，混在しての運用は不可
・ストレージに dets を指定した場合，dets フォーマットの互換性あり
つまり，混在しての運用はできないが，設定ファイルや dets ファイルは変更不要，ということです．
2009/6/3 Takeru INOUE <tak...@gm...>:
> 一通り，リファクタリングが終わりました．
>
> といっても，主にやったことはリファクタリングっぽくないのですが．．
>
> ・テストの追加・修正
> ・設定の変更・追加
> - n,r,w → quorum
> - number_of_buckets → buckets
> - number_of_virtual_nodes → virtual_nodes
> - number_of_tables → dets_tables
> - sync_interval (データ同期間隔)
> - membership_interval (メンバシップ同期間隔)
> ・kai_config へのアクセスを起動時に限定
> - 各モジュールは必要な設定を起動時にコピー
> - 第二回 erlang 勉強会で言っていた問題の解決
> ・戻り値が単一種の関数は，戻り値のタグを {XXX, ...} から {ok, ...} に変更
> ・などなど
>
> 問題なさそうなら，そのうちに trunk/ に merge しておきます．
>
> この先は，
>
> ・dets 書き込みの高速化
> ・データ同期の高速化
> ・ノード追加の簡易化 (check_node はわかりにくいので)
> ・複数バージョン扱いの修正
> ・などなど
>
> の予定です (順不同)．
>
>
> 2009/6/3 Takeru INOUE <tak...@gm...>:
>> 2009/6/1 masahito ikuta <coo...@gm...>:
>>>>> net_kernel:start/1, slave:start/3 を使うと
>>>>> カバレッジを管理するノードがモジュールをロードしないからだと思います。
>>>>>
>>>>> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・
>>>>> 本家 ML で聞いた方が良いかもしれません。
>>>
>>> よくよく考えてみると、テスト対象のモジュールは、カレントノードにロードし
>>> ノード間通信の相手側だけ、別ノードでロードさせるのが
>>> あるべき姿のような気がしますが、如何でしょうか？
>>
>> そうだと思いますが，以下の二つの理由でいまのようなテスト実装になりました．
>>
>> ・カレントノードにロードしたら，kai_rpc で接続エラーになった (何かを間違っていたのかもしれないけど)
>> ・kai_sync のように，対になって動作するモジュールの場合 (A, B 二種類の処理ルーチンがやりとりしながら動作するということ)，A
>> をカレントノードにロードするテストと，B をロードするテストを，別々に書かなければならない．
>>
>> ひとつめが解決したら直すかなぁ．
>>
>>> ちなみに、ermlia のノード間通信のテストは、mock を作りまくって対応していましたが
>>> 無駄に Module のメタ操作をしていた為、カバレッジが初期化されてしまいました（w；
>>
>> それほど Erlang のことをわかってないので，メタ操作をするのはちょっと怖いなぁ．
>>
>>>>>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ．
>>>>
>>>> こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)．
>>>
>>> 私の好みは、number_of_XXX ですが
>>> XXX の方が一般的（根拠なし）な気もしています。
>>> 一般的な方で良いと思います。
>>
>> もうちょっと考えてみますね．
>>
>>
>>> 2009/5/31 Takeru INOUE <tak...@gm...>:
>>>>>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ?
>>>>>
>>>>> net_kernel:start/1, slave:start/3 を使うと
>>>>> カバレッジを管理するノードがモジュールをロードしないからだと思います。
>>>>>
>>>>> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・
>>>>> 本家 ML で聞いた方が良いかもしれません。
>>>>>
>>>>> むー、test_server を使えば回避できるのかなー？
>>>>
>>>> そうなのかぁ．
>>>>
>>>> # ML に尋ねるのは，せめて test_server を試してからだよなぁ．とか言ってると，どんどん後回しになる．．
>>>>
>>>>>> n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました．
>>>>>
>>>>> number_of_tables は、ets には関係ないので、その名前が良いと思います。
>>>>
>>>> ではこの線でいきます．
>>>>
>>>>>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ．
>>>>
>>>> こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)．
>>>>
>>>>>> rpc_max_processes, memcache_max_processes, max_connections
>>>>>> のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)．
>>>>>> 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)．
>>>>>>
>>>>>> quorum 条件のチェックを追加しました．
>>>>>> R+W > N と W > N/2 を満たさないときはエラーになります．
>>>>>>
>>>>>>
>>>>>> 2009/5/28 Takeru INOUE <tak...@gm...>:
>>>>>>> 先ほど，test/ を大幅に追加・修正してコミットしました．
>>>>>>> 時間のある方は試して，問題があったら連絡しくださると助かります．
>>>>>>>
>>>>>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ?
>>>>>>>
>>>>>>> なお，src/ はほとんど変更していません．
>>>>>>> kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです．
>>>>>>>
>>>>>>>
>>>>>>> 2009/5/23 Takeru INOUE <tak...@gm...>:
>>>>>>>> 2009/5/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．
>>>>>>>>>
>>>>>>>>> 非同期にすると、信頼性が落ちそうなので
>>>>>>>>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが
>>>>>>>>> 如何でしょうか？
>>>>>>>>
>>>>>>>> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね．
>>>>>>>> あぁ，設定項目が増えていく．．
>>>>>>>> 苦情が来てからにしようかなぁ．．
>>>>>>>>
>>>>>>>>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが
>>>>>>>>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？
>>>>>>>>> 後で、検証しないと・・・。
>>>>>>>>
>>>>>>>> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．．
>>>>>>>> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ．
>>>>>>>>
>>>>>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．
>>>>>>>>>
>>>>>>>>> バージョン番号が 1.0 に到達していないので
>>>>>>>>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。
>>>>>>>>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。
>>>>>>>>
>>>>>>>> 必要な修正なので，いずれはやります．
>>>>>>>>
>>>>>>>>> 2009/5/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> コードの整理やテストの充実のために，リファクタリングしようと思っています．
>>>>>>>>>> そのための branch を作りました．
>>>>>>>>>>
>>>>>>>>>> branches/takemaru_refactoring/
>>>>>>>>>>
>>>>>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です．
>>>>>>>>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので．
>>>>>>>>>>
>>>>>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます．
>>>>>>>>>> 並行して考えていきます．
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Takeru INOUE
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>>>>>>>>> is a gathering of tech-side developers & brand creativity professionals. Meet
>>>>>>>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>>>>>>>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>>>>>>>>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>> Kai...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Takeru INOUE
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Takeru INOUE
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Takeru INOUE
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> cooldaemon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Takeru INOUE
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>> Takeru INOUE
>>
>
>
>
> --
> Takeru INOUE
>
--
Takeru INOUE
|
|
From: Takeru I. <tak...@gm...> - 2009-06-02 15:26:27
|
2009/6/1 masahito ikuta <coo...@gm...>: >>> net_kernel:start/1, slave:start/3 を使うと >>> カバレッジを管理するノードがモジュールをロードしないからだと思います。 >>> >>> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・ >>> 本家 ML で聞いた方が良いかもしれません。 > > よくよく考えてみると、テスト対象のモジュールは、カレントノードにロードし > ノード間通信の相手側だけ、別ノードでロードさせるのが > あるべき姿のような気がしますが、如何でしょうか？ そうだと思いますが，以下の二つの理由でいまのようなテスト実装になりました． ・カレントノードにロードしたら，kai_rpc で接続エラーになった (何かを間違っていたのかもしれないけど) ・kai_sync のように，対になって動作するモジュールの場合 (A, B 二種類の処理ルーチンがやりとりしながら動作するということ)，A をカレントノードにロードするテストと，B をロードするテストを，別々に書かなければならない． ひとつめが解決したら直すかなぁ． > ちなみに、ermlia のノード間通信のテストは、mock を作りまくって対応していましたが > 無駄に Module のメタ操作をしていた為、カバレッジが初期化されてしまいました（w； それほど Erlang のことをわかってないので，メタ操作をするのはちょっと怖いなぁ． >>>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． >> >> こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)． > > 私の好みは、number_of_XXX ですが > XXX の方が一般的（根拠なし）な気もしています。 > 一般的な方で良いと思います。 もうちょっと考えてみますね． > 2009/5/31 Takeru INOUE <tak...@gm...>: >>>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? >>> >>> net_kernel:start/1, slave:start/3 を使うと >>> カバレッジを管理するノードがモジュールをロードしないからだと思います。 >>> >>> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・ >>> 本家 ML で聞いた方が良いかもしれません。 >>> >>> むー、test_server を使えば回避できるのかなー？ >> >> そうなのかぁ． >> >> # ML に尋ねるのは，せめて test_server を試してからだよなぁ．とか言ってると，どんどん後回しになる．． >> >>>> n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました． >>> >>> number_of_tables は、ets には関係ないので、その名前が良いと思います。 >> >> ではこの線でいきます． >> >>>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． >> >> こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)． >> >>>> rpc_max_processes, memcache_max_processes, max_connections >>>> のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)． >>>> 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)． >>>> >>>> quorum 条件のチェックを追加しました． >>>> R+W > N と W > N/2 を満たさないときはエラーになります． >>>> >>>> >>>> 2009/5/28 Takeru INOUE <tak...@gm...>: >>>>> 先ほど，test/ を大幅に追加・修正してコミットしました． >>>>> 時間のある方は試して，問題があったら連絡しくださると助かります． >>>>> >>>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? >>>>> >>>>> なお，src/ はほとんど変更していません． >>>>> kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです． >>>>> >>>>> >>>>> 2009/5/23 Takeru INOUE <tak...@gm...>: >>>>>> 2009/5/23 masahito ikuta <coo...@gm...>: >>>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>>>> >>>>>>> 非同期にすると、信頼性が落ちそうなので >>>>>>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが >>>>>>> 如何でしょうか？ >>>>>> >>>>>> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． >>>>>> あぁ，設定項目が増えていく．． >>>>>> 苦情が来てからにしようかなぁ．． >>>>>> >>>>>>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが >>>>>>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ >>>>>>> 後で、検証しないと・・・。 >>>>>> >>>>>> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． >>>>>> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． >>>>>> >>>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>>>> >>>>>>> バージョン番号が 1.0 に到達していないので >>>>>>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 >>>>>>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。 >>>>>> >>>>>> 必要な修正なので，いずれはやります． >>>>>> >>>>>>> 2009/5/22 Takeru INOUE <tak...@gm...>: >>>>>>>> コードの整理やテストの充実のために，リファクタリングしようと思っています． >>>>>>>> そのための branch を作りました． >>>>>>>> >>>>>>>> branches/takemaru_refactoring/ >>>>>>>> >>>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>>>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >>>>>>>> >>>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>>>>> 並行して考えていきます． >>>>>>>> >>>>>>>> -- >>>>>>>> Takeru INOUE >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>>>>>>> is a gathering of tech-side developers & brand creativity professionals. Meet >>>>>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>>>>>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >>>>>>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >>>>>>>> _______________________________________________ >>>>>>>> Kai-devel-ja mailing list >>>>>>>> Kai...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> cooldaemon >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Takeru INOUE >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Takeru INOUE >>>>> >>>> >>>> >>>> >>>> -- >>>> Takeru INOUE >>>> >>> >>> >>> >>> -- >>> cooldaemon >>> >> >> >> >> -- >> Takeru INOUE >> > > > > -- > cooldaemon > -- Takeru INOUE |
|
From: masahito i. <coo...@gm...> - 2009-06-01 02:32:12
|
>> net_kernel:start/1, slave:start/3 を使うと >> カバレッジを管理するノードがモジュールをロードしないからだと思います。 >> >> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・ >> 本家 ML で聞いた方が良いかもしれません。 よくよく考えてみると、テスト対象のモジュールは、カレントノードにロードし ノード間通信の相手側だけ、別ノードでロードさせるのが あるべき姿のような気がしますが、如何でしょうか？ ちなみに、ermlia のノード間通信のテストは、mock を作りまくって対応していましたが 無駄に Module のメタ操作をしていた為、カバレッジが初期化されてしまいました（w； >>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． > > こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)． 私の好みは、number_of_XXX ですが XXX の方が一般的（根拠なし）な気もしています。 一般的な方で良いと思います。 2009/5/31 Takeru INOUE <tak...@gm...>: >>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? >> >> net_kernel:start/1, slave:start/3 を使うと >> カバレッジを管理するノードがモジュールをロードしないからだと思います。 >> >> かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・ >> 本家 ML で聞いた方が良いかもしれません。 >> >> むー、test_server を使えば回避できるのかなー？ > > そうなのかぁ． > > # ML に尋ねるのは，せめて test_server を試してからだよなぁ．とか言ってると，どんどん後回しになる．． > >>> n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました． >> >> number_of_tables は、ets には関係ないので、その名前が良いと思います。 > > ではこの線でいきます． > >>> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． > > こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)． > >>> rpc_max_processes, memcache_max_processes, max_connections >>> のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)． >>> 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)． >>> >>> quorum 条件のチェックを追加しました． >>> R+W > N と W > N/2 を満たさないときはエラーになります． >>> >>> >>> 2009/5/28 Takeru INOUE <tak...@gm...>: >>>> 先ほど，test/ を大幅に追加・修正してコミットしました． >>>> 時間のある方は試して，問題があったら連絡しくださると助かります． >>>> >>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? >>>> >>>> なお，src/ はほとんど変更していません． >>>> kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです． >>>> >>>> >>>> 2009/5/23 Takeru INOUE <tak...@gm...>: >>>>> 2009/5/23 masahito ikuta <coo...@gm...>: >>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>>> >>>>>> 非同期にすると、信頼性が落ちそうなので >>>>>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが >>>>>> 如何でしょうか？ >>>>> >>>>> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． >>>>> あぁ，設定項目が増えていく．． >>>>> 苦情が来てからにしようかなぁ．． >>>>> >>>>>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが >>>>>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ >>>>>> 後で、検証しないと・・・。 >>>>> >>>>> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． >>>>> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． >>>>> >>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>>> >>>>>> バージョン番号が 1.0 に到達していないので >>>>>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 >>>>>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。 >>>>> >>>>> 必要な修正なので，いずれはやります． >>>>> >>>>>> 2009/5/22 Takeru INOUE <tak...@gm...>: >>>>>>> コードの整理やテストの充実のために，リファクタリングしようと思っています． >>>>>>> そのための branch を作りました． >>>>>>> >>>>>>> branches/takemaru_refactoring/ >>>>>>> >>>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >>>>>>> >>>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>>>> 並行して考えていきます． >>>>>>> >>>>>>> -- >>>>>>> Takeru INOUE >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>>>>>> is a gathering of tech-side developers & brand creativity professionals. Meet >>>>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>>>>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >>>>>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >>>>>>> _______________________________________________ >>>>>>> Kai-devel-ja mailing list >>>>>>> Kai...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> cooldaemon >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Takeru INOUE >>>>> >>>> >>>> >>>> >>>> -- >>>> Takeru INOUE >>>> >>> >>> >>> >>> -- >>> Takeru INOUE >>> >> >> >> >> -- >> cooldaemon >> > > > > -- > Takeru INOUE > -- cooldaemon |
|
From: Takeru I. <tak...@gm...> - 2009-05-31 13:03:17
|
>>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? > > net_kernel:start/1, slave:start/3 を使うと > カバレッジを管理するノードがモジュールをロードしないからだと思います。 > > かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・ > 本家 ML で聞いた方が良いかもしれません。 > > むー、test_server を使えば回避できるのかなー？ そうなのかぁ． # ML に尋ねるのは，せめて test_server を試してからだよなぁ．とか言ってると，どんどん後回しになる．． >> n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました． > > number_of_tables は、ets には関係ないので、その名前が良いと思います。 ではこの線でいきます． >> ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． こちらについても，気が向いたら変えてしまうかもしれません (後方互換性は維持したまま)． >> rpc_max_processes, memcache_max_processes, max_connections >> のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)． >> 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)． >> >> quorum 条件のチェックを追加しました． >> R+W > N と W > N/2 を満たさないときはエラーになります． >> >> >> 2009/5/28 Takeru INOUE <tak...@gm...>: >>> 先ほど，test/ を大幅に追加・修正してコミットしました． >>> 時間のある方は試して，問題があったら連絡しくださると助かります． >>> >>> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? >>> >>> なお，src/ はほとんど変更していません． >>> kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです． >>> >>> >>> 2009/5/23 Takeru INOUE <tak...@gm...>: >>>> 2009/5/23 masahito ikuta <coo...@gm...>: >>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>> >>>>> 非同期にすると、信頼性が落ちそうなので >>>>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが >>>>> 如何でしょうか？ >>>> >>>> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． >>>> あぁ，設定項目が増えていく．． >>>> 苦情が来てからにしようかなぁ．． >>>> >>>>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが >>>>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ >>>>> 後で、検証しないと・・・。 >>>> >>>> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． >>>> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． >>>> >>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>> >>>>> バージョン番号が 1.0 に到達していないので >>>>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 >>>>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。 >>>> >>>> 必要な修正なので，いずれはやります． >>>> >>>>> 2009/5/22 Takeru INOUE <tak...@gm...>: >>>>>> コードの整理やテストの充実のために，リファクタリングしようと思っています． >>>>>> そのための branch を作りました． >>>>>> >>>>>> branches/takemaru_refactoring/ >>>>>> >>>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >>>>>> >>>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>>> 並行して考えていきます． >>>>>> >>>>>> -- >>>>>> Takeru INOUE >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>>>>> is a gathering of tech-side developers & brand creativity professionals. Meet >>>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>>>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >>>>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >>>>>> _______________________________________________ >>>>>> Kai-devel-ja mailing list >>>>>> Kai...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> cooldaemon >>>>> >>>> >>>> >>>> >>>> -- >>>> Takeru INOUE >>>> >>> >>> >>> >>> -- >>> Takeru INOUE >>> >> >> >> >> -- >> Takeru INOUE >> > > > > -- > cooldaemon > -- Takeru INOUE |
|
From: masahito i. <coo...@gm...> - 2009-05-30 02:29:33
|
幾田です。 ちょっとお出かけ前で時間が無いので、ささっと解るところだけ。 >> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? net_kernel:start/1, slave:start/3 を使うと カバレッジを管理するノードがモジュールをロードしないからだと思います。 かと言って、Kai を一ノードで複数起動させるのも変な話ですし・・・ 本家 ML で聞いた方が良いかもしれません。 むー、test_server を使えば回避できるのかなー？ > n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました． number_of_tables は、ets には関係ないので、その名前が良いと思います。 2009/5/29 Takeru INOUE <tak...@gm...>: > 先ほど，設定関連の修正を行いました． > > n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました． > なお，古い設定名もまだ有効です (warning 出ます)． > ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． > > rpc_max_processes, memcache_max_processes, max_connections > のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)． > 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)． > > quorum 条件のチェックを追加しました． > R+W > N と W > N/2 を満たさないときはエラーになります． > > > 2009/5/28 Takeru INOUE <tak...@gm...>: >> 先ほど，test/ を大幅に追加・修正してコミットしました． >> 時間のある方は試して，問題があったら連絡しくださると助かります． >> >> ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? >> >> なお，src/ はほとんど変更していません． >> kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです． >> >> >> 2009/5/23 Takeru INOUE <tak...@gm...>: >>> 2009/5/23 masahito ikuta <coo...@gm...>: >>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>> >>>> 非同期にすると、信頼性が落ちそうなので >>>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが >>>> 如何でしょうか？ >>> >>> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． >>> あぁ，設定項目が増えていく．． >>> 苦情が来てからにしようかなぁ．． >>> >>>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが >>>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ >>>> 後で、検証しないと・・・。 >>> >>> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． >>> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． >>> >>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>> >>>> バージョン番号が 1.0 に到達していないので >>>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 >>>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。 >>> >>> 必要な修正なので，いずれはやります． >>> >>>> 2009/5/22 Takeru INOUE <tak...@gm...>: >>>>> コードの整理やテストの充実のために，リファクタリングしようと思っています． >>>>> そのための branch を作りました． >>>>> >>>>> branches/takemaru_refactoring/ >>>>> >>>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >>>>> >>>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>>> 並行して考えていきます． >>>>> >>>>> -- >>>>> Takeru INOUE >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>>>> is a gathering of tech-side developers & brand creativity professionals. Meet >>>>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >>>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >>>>> _______________________________________________ >>>>> Kai-devel-ja mailing list >>>>> Kai...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >>>>> >>>> >>>> >>>> >>>> -- >>>> cooldaemon >>>> >>> >>> >>> >>> -- >>> Takeru INOUE >>> >> >> >> >> -- >> Takeru INOUE >> > > > > -- > Takeru INOUE > -- cooldaemon |
|
From: Takeru I. <tak...@gm...> - 2009-05-29 14:23:55
|
先ほど，設定関連の修正を行いました． n,r,w と number_of_tables という設定項目名を，quorum と dets_number_of_tables にしました． なお，古い設定名もまだ有効です (warning 出ます)． ところで，number_of_XXX という設定名は，XXX のみのほうが簡潔でいいですかねぇ． rpc_max_processes, memcache_max_processes, max_connections のデフォルト値を大きくしました (大きい値で困ることは少なそうなので)． 逆に，dets_number_of_tables のデフォルト値を小さくしました (MacOSX でエラーになるようなので)． quorum 条件のチェックを追加しました． R+W > N と W > N/2 を満たさないときはエラーになります． 2009/5/28 Takeru INOUE <tak...@gm...>: > 先ほど，test/ を大幅に追加・修正してコミットしました． > 時間のある方は試して，問題があったら連絡しくださると助かります． > > ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? > > なお，src/ はほとんど変更していません． > kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです． > > > 2009/5/23 Takeru INOUE <tak...@gm...>: >> 2009/5/23 masahito ikuta <coo...@gm...>: >>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>> >>> 非同期にすると、信頼性が落ちそうなので >>> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが >>> 如何でしょうか？ >> >> 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． >> あぁ，設定項目が増えていく．． >> 苦情が来てからにしようかなぁ．． >> >>> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが >>> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ >>> 後で、検証しないと・・・。 >> >> TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． >> たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． >> >>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>> >>> バージョン番号が 1.0 に到達していないので >>> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 >>> ＃とは言いつつ、ユーザの声は大切ですよね・・・。 >> >> 必要な修正なので，いずれはやります． >> >>> 2009/5/22 Takeru INOUE <tak...@gm...>: >>>> コードの整理やテストの充実のために，リファクタリングしようと思っています． >>>> そのための branch を作りました． >>>> >>>> branches/takemaru_refactoring/ >>>> >>>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >>>> >>>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>>> 並行して考えていきます． >>>> >>>> -- >>>> Takeru INOUE >>>> >>>> ------------------------------------------------------------------------------ >>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>>> is a gathering of tech-side developers & brand creativity professionals. Meet >>>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >>>> _______________________________________________ >>>> Kai-devel-ja mailing list >>>> Kai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >>>> >>> >>> >>> >>> -- >>> cooldaemon >>> >> >> >> >> -- >> Takeru INOUE >> > > > > -- > Takeru INOUE > -- Takeru INOUE |
|
From: Takeru I. <tak...@gm...> - 2009-05-28 14:26:01
|
先ほど，test/ を大幅に追加・修正してコミットしました． 時間のある方は試して，問題があったら連絡しくださると助かります． ところで，coverage が正しく反映されていないように見えるのですが，何か必要なのでしたっけ? なお，src/ はほとんど変更していません． kai_stat, kai_memcache の小さなバグと，kai_rpc にテスト用の ok コマンドを追加しただけです． 2009/5/23 Takeru INOUE <tak...@gm...>: > 2009/5/23 masahito ikuta <coo...@gm...>: >>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >> >> 非同期にすると、信頼性が落ちそうなので >> MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが >> 如何でしょうか？ > > 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． > あぁ，設定項目が増えていく．． > 苦情が来てからにしようかなぁ．． > >> 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが >> ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ >> 後で、検証しないと・・・。 > > TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． > たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． > >>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >> >> バージョン番号が 1.0 に到達していないので >> 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 >> ＃とは言いつつ、ユーザの声は大切ですよね・・・。 > > 必要な修正なので，いずれはやります． > >> 2009/5/22 Takeru INOUE <tak...@gm...>: >>> コードの整理やテストの充実のために，リファクタリングしようと思っています． >>> そのための branch を作りました． >>> >>> branches/takemaru_refactoring/ >>> >>> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >>> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >>> >>> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >>> 並行して考えていきます． >>> >>> -- >>> Takeru INOUE >>> >>> ------------------------------------------------------------------------------ >>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >>> is a gathering of tech-side developers & brand creativity professionals. Meet >>> the minds behind Google Creative Lab, Visual Complexity, Processing, & >>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >>> _______________________________________________ >>> Kai-devel-ja mailing list >>> Kai...@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >>> >> >> >> >> -- >> cooldaemon >> > > > > -- > Takeru INOUE > -- Takeru INOUE |
|
From: Takeru I. <tak...@gm...> - 2009-05-24 14:05:36
|
> > src/kai_version.erl の State#state.vector_clocks は機能していないようにみえるけど，使う予定がある? > 現状、利用していません。ので削ります。 了解です． >>> test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? >> >> ずっとさわっていないので、ちょっとログ見て、記憶をよびおこします。 >> 少々おまちください。 > > 最初から all() に抜けていたのは凡ミスでした。追加しました。 > 抜けていたテストで(test_merge) assertion が逆になっていたので > 修正しました。 こちらも了解です． 両方とも，branches/takemaru_refactoring/ に merge しました． > 見てもらってありがとうございました m(_ _)m いえいえ，昔の話をいまさら蒸し返してしまってごめんなさい． >> 2009/5/23 Takeru INOUE <tak...@gm...>: >>> vclock と kai_version についての確認メールです． >>> >>> test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? >>> >>> src/kai_version.erl の State#state.vector_clocks は機能していないようにみえるけど，使う予定がある? >>> >>> 2008/11/28 Takeru INOUE <tak...@gm...>: >>>> 2008/11/28 shunichi shinohara <shi...@gm...>: >>>>> 2008/11/26 Takeru INOUE <tak...@gm...>: >>>>>> そろそろ trunk にマージします? >>>>> >>>>> trunk にマージしました。 >>>>> 中身はブランチのものそのままです。 >>>>> >>>>> ずいぶんおそくなってもうしわけないです。 >>>> >>>> おつかれっす． >>>> >>>>> # そろそろ、次のリリースになるのでしょうか? >>>> >>>> そうしようかなぁ． >>>> 新ノードの join を簡単にするコードを書いてからと思ってるんだけど，遅くなりそうだったらリリースしちゃいます． >>>> > -- Takeru INOUE |
|
From: shunichi s. <shi...@gm...> - 2009-05-24 01:25:03
|
しのはらです。 2009/5/24 shunichi shinohara <shi...@gm...>: >> test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? > > ずっとさわっていないので、ちょっとログ見て、記憶をよびおこします。 > 少々おまちください。 最初から all() に抜けていたのは凡ミスでした。追加しました。 抜けていたテストで(test_merge) assertion が逆になっていたので 修正しました。 見てもらってありがとうございました m(_ _)m shino > 2009/5/23 Takeru INOUE <tak...@gm...>: >> vclock と kai_version についての確認メールです． >> >> test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? >> >> src/kai_version.erl の State#state.vector_clocks は機能していないようにみえるけど，使う予定がある? >> >> 2008/11/28 Takeru INOUE <tak...@gm...>: >>> 2008/11/28 shunichi shinohara <shi...@gm...>: >>>> 2008/11/26 Takeru INOUE <tak...@gm...>: >>>>> そろそろ trunk にマージします? >>>> >>>> trunk にマージしました。 >>>> 中身はブランチのものそのままです。 >>>> >>>> ずいぶんおそくなってもうしわけないです。 >>> >>> おつかれっす． >>> >>>> # そろそろ、次のリリースになるのでしょうか? >>> >>> そうしようかなぁ． >>> 新ノードの join を簡単にするコードを書いてからと思ってるんだけど，遅くなりそうだったらリリースしちゃいます． >>> |
|
From: shunichi s. <shi...@gm...> - 2009-05-24 00:58:20
|
しのはらです。 > src/kai_version.erl の State#state.vector_clocks は機能していないようにみえるけど，使う予定がある? 現状、利用していません。ので削ります。 > test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? ずっとさわっていないので、ちょっとログ見て、記憶をよびおこします。 少々おまちください。 shino 2009/5/23 Takeru INOUE <tak...@gm...>: > vclock と kai_version についての確認メールです． > > test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? > > src/kai_version.erl の State#state.vector_clocks は機能していないようにみえるけど，使う予定がある? > > 2008/11/28 Takeru INOUE <tak...@gm...>: >> 2008/11/28 shunichi shinohara <shi...@gm...>: >>> 2008/11/26 Takeru INOUE <tak...@gm...>: >>>> そろそろ trunk にマージします? >>> >>> trunk にマージしました。 >>> 中身はブランチのものそのままです。 >>> >>> ずいぶんおそくなってもうしわけないです。 >> >> おつかれっす． >> >>> # そろそろ、次のリリースになるのでしょうか? >> >> そうしようかなぁ． >> 新ノードの join を簡単にするコードを書いてからと思ってるんだけど，遅くなりそうだったらリリースしちゃいます． >> >>> --- >>> shino >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > > > -- > Takeru INOUE > -- shino |
|
From: Takeru I. <tak...@gm...> - 2009-05-23 14:45:15
|
vclock と kai_version についての確認メールです． test/vclock_SUITE.erl のいくつかのテストが実行されないようになっているのには，何か意図がある? src/kai_version.erl の State#state.vector_clocks は機能していないようにみえるけど，使う予定がある? 2008/11/28 Takeru INOUE <tak...@gm...>: > 2008/11/28 shunichi shinohara <shi...@gm...>: >> 2008/11/26 Takeru INOUE <tak...@gm...>: >>> そろそろ trunk にマージします? >> >> trunk にマージしました。 >> 中身はブランチのものそのままです。 >> >> ずいぶんおそくなってもうしわけないです。 > > おつかれっす． > >> # そろそろ、次のリリースになるのでしょうか? > > そうしようかなぁ． > 新ノードの join を簡単にするコードを書いてからと思ってるんだけど，遅くなりそうだったらリリースしちゃいます． > >> --- >> shino >> > > > > -- > Takeru INOUE <tak...@gm...> > -- Takeru INOUE |
|
From: Takeru I. <tak...@gm...> - 2009-05-23 14:30:34
|
2009/5/23 masahito ikuta <coo...@gm...>: >> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． > > 非同期にすると、信頼性が落ちそうなので > MySQL のように、オプションで同期タイミングを選択できると良いなぁと思いますが > 如何でしょうか？ 複製があるのでほとんどの場合は問題ないと思うのですが，あったほうが親切ですよね． あぁ，設定項目が増えていく．． 苦情が来てからにしようかなぁ．． > 他に、TC を使う等で書き込み速度自体を上げる手もありそうですが > ポートを使った場合、ノード全体がロックされてボトルネックになるかも？ > 後で、検証しないと・・・。 TC のような外部コンポーネントと組み合わせると，どうしてもシステムが複雑になってしまうので，これも二の足を踏んでます．． たぶん，非同期書き込みにすれば dets でもそれなりに速くなるんじゃないかなぁと根拠のない期待をしつつ． >> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． > > バージョン番号が 1.0 に到達していないので > 後方互換を保つ事の優先順位を下げる事に一票入れておきます。 > ＃とは言いつつ、ユーザの声は大切ですよね・・・。 必要な修正なので，いずれはやります． > 2009/5/22 Takeru INOUE <tak...@gm...>: >> コードの整理やテストの充実のために，リファクタリングしようと思っています． >> そのための branch を作りました． >> >> branches/takemaru_refactoring/ >> >> その後で，非同期書き込みによる dets の高速化や，データ同期の高速化を行う予定です． >> 後者については，同期のための CPU 負荷が高いという声を耳にしたので． >> >> 別のスレッドで複数値の格納が TODO になっているのですが，後方互換性が失われるので，二の足を踏んでます． >> 並行して考えていきます． >> >> -- >> Takeru INOUE >> >> ------------------------------------------------------------------------------ >> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT >> is a gathering of tech-side developers & brand creativity professionals. Meet >> the minds behind Google Creative Lab, Visual Complexity, Processing, & >> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian >> Group, R/GA, & Big Spaceship. http://www.creativitycat.com >> _______________________________________________ >> Kai-devel-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja >> > > > > -- > cooldaemon > -- Takeru INOUE |
