-
- いいね！0
methane
@methane
@moriyoshit routerをリエントラントにするのがシンプルさと性能の両立しやすいのかなぁと思ってます。inputの並列度以上に router の並列度が必要な場面は今のところないと思うし。
2014-06-12 14:42:14
Moriyoshi Koizumi
@moriyoshit
@methane router自体はステートフルではないので、今のままリエントラントにしても問題無いと思います。ご指摘のようにプラグインがスレッド安全性を担保するということにして。
2014-06-12 14:43:21
Moriyoshi Koizumi
@moriyoshit
(そもそも Emit で詰まってほしくないので、プラグイン内部で channel を使う想定ではある。)
2014-06-12 14:45:12
tagomoris
@tagomoris
@methane 次に作り直すときにTCP keepaliveを入れるつもりなので、それが入ったらその方法は採れる道がひらけるのは元々考慮にはあります (v11 branchのforwardとsecure-forwardあたりにそれぞれ片鱗がある)
2014-06-12 14:45:50
SKS rep
@repeatedly
@tagomoris 先にsecure-forwardでやってしまえばいいのでは！？コア部分ってなんか改良必要なんですっけ？actorがないとv11のforwardはもってこられない気はしますが，他の部分とかなら内部の改善そのものは出来る
2014-06-12 14:50:00
Moriyoshi Koizumi
@moriyoshit
そういえば fluent の buffer の id の話があったけど、chunk の大きさの単位ってちょっと再送のことを考えるには恣意的すぎるような気もするんですがどうなんでしょう。
2014-06-12 14:51:37
SKS rep
@repeatedly
もう一つの解決策は，あなたがFluentdをフルタイムで開発することですね！ > "トレジャーデータ | キャリア | Fluentd開発者" treasuredata.com/jp/careers/car…
2014-06-12 14:52:38
SKS rep
@repeatedly
@tagomoris 結局は時間か．secure-forward，前試したらパフォーマンスはそんなに落ちなかったので，そういう安全性に関してはsecure-forwardで頑張っても良いのかなと個人的には思っては居ます
2014-06-12 14:53:17
SKS rep
@repeatedly
secure-fowardはforwardと違って毎回コネクション貼るのがコスト掛かりすぎるのでつなぎっぱにしているのとも，大きい気がする
2014-06-12 14:54:03
tagomoris
@tagomoris
@repeatedly あと基本的にForwardの上位互換のはずなので、固まってしまえばactor版Forwardに書き直す + SSL対応もやってしまう、というのが理想的な道
2014-06-12 14:54:10