-
- いいね！0
Sadayuki Furuhashi
@frsyuki
MessagePack-RPC Java版の例外周りの実装の遅れがここに来て影響を見せ始めてマズイ。必須だけど設計が難しい…。
2011-02-25 12:46:29
Sadayuki Furuhashi
@frsyuki
投げられ得る例外の一覧は厳密にはInvokerに結びついている必要があって、ちょぃと使い勝手を重視してSessionでも良いとしても、シングルトンにするわけにはいかない。例外セットみたいなクラスを作る必要があるか。
2011-02-25 12:54:16
Sadayuki Furuhashi
@frsyuki
Session.proxy(Class<T> iface) を Session.proxy(Class<T> iface, ExceptionSet errors) にすればいいのか。
2011-02-25 12:56:21
Sadayuki Furuhashi
@frsyuki
あとFutureのメンバにExceptionSetを持たせて、.checkThrowError()で処理。あとはInvoker側でRemoteErrorのサブクラス群をcatchしてErrorObjectを返す。新規実装はExceptionSetとErrorObject。
2011-02-25 12:59:07
Sadayuki Furuhashi
@frsyuki
ぁぁ案外にシンプルに収まる予感。ExceptionSetの実装がかなりキモ。これで例外の継承を実現する必要がある。
2011-02-25 13:00:49
Sadayuki Furuhashi
@frsyuki
@muga_nishizawa そうですそうです。アプリケーションの起動時あたりで、static ExceptionSet myRpcExs = new ExceptionSet(); myRpcExs.add(NotFoundError.class); とやっておき、
2011-02-25 13:02:08
Sadayuki Furuhashi
@frsyuki
@muga_nishizawa 使うときは session.proxy(MyRpcIface.class, myRpcExcs) とやるイメージです。
2011-02-25 13:02:27
Muga Nishizawa
@muga_nishizawa
@frsyuki MyRpcIface.class に宣言されている method の signature から exceptions を reflection で抽出できるのではないですか？
2011-02-25 13:03:49
Sadayuki Furuhashi
@frsyuki
こっちの方が断然いい！ RT @muga_nishizawa: @frsyuki MyRpcIface.class に宣言されている method の signature から exceptions を reflection で抽出できるのではないですか？
2011-02-25 13:04:35
Sadayuki Furuhashi
@frsyuki
プロトコルは2要素のタプルで、RemoteError.SuperError.SubError という感じで継承関係を.で繋いだ文字列（Raw）と、そのクラスをシリアライズした配列。ExceptionSetの中にSubErrorが見つからなかったら、SuperErrorで投げる。
2011-02-25 13:06:12
Muga Nishizawa
@muga_nishizawa
@frsyuki そうですそうです。API を変えずにいけるかと思いますー RT @frsyuki: reflectionでExceptionSetの作成を自動化する感じかな。
2011-02-25 13:06:36
Sadayuki Furuhashi
@frsyuki
SuperErrorも見つからなかったら、最後の最後はRemoteErrorで投げる。この辺りの処理はHashMapかTreeMapでうまく実装できそうかな。あと組み込みでNoMethodErrorとか。
2011-02-25 13:06:51
Sadayuki Furuhashi
@frsyuki
ただ既存の仕様は任意のオブジェクトになっているので、これと互換性のある形で実装が必要。getError()が配列で、先頭要素がRaw型で、2番目の要素がArrayだった場合のみこの処理方法。そうでなければnew RemoteError(getError())で互換性維持。
2011-02-25 13:07:55
Sadayuki Furuhashi
@frsyuki
Future。組み込みエラーの種類は http://bit.ly/gAHayA このあたりで考えたりしたけど、RMIとかどうせテキトーなので、設計ミスを恐れずとりあえず実装してみるしかない気がしている。あとは任せた…！（ﾊﾞﾀｯ
2011-02-25 13:13:51
Sadayuki Furuhashi
@frsyuki
さっきの古いな。2010-10-01 23:12:46 と言うわけでエラーはこうなる。「正しい」気がする。正しいのが使いやすいとは限らない… http://bit.ly/bfZdnv
2011-02-25 13:24:35
Sadayuki Furuhashi
@frsyuki
ぁあった。「TR1はオプションで無効化できるなら使ってヨシ」というオレルールなのだけど、VC++やclangにもあるならMessagePackで使いたいな。
2011-02-27 22:56:26
Sadayuki Furuhashi
@frsyuki
あるある。enumをint&にキャストするstrict-aliasing rule問題を解決できるかも。http://bit.ly/hq9n38 http://bit.ly/fpPxoe
2011-02-27 22:57:56
Sadayuki Furuhashi
@frsyuki
というのも最近新しくした環境でMessagePackのテストを走らせたら、enumのところでstrict aliasing ruleのエラーが…。
2011-02-27 23:05:48
Sadayuki Furuhashi
@frsyuki
できた。MessagePack for C++で、enumのデシリアライズ時のstrict-aliasingを解決できる。でも本体側に手を入れる必要があって、実装方法が若干微妙…。
2011-02-27 23:49:01
Sadayuki Furuhashi
@frsyuki
設計を改善して0.6を出したい。そろそろdirect conversionとdeconvertを入れたいところ。
2011-02-27 23:51:26
Sadayuki Furuhashi
@frsyuki
あと野望としてはバッファの抽象化を入れたい。RPCでスレッド間で共有できるメモリプールとmmapアロケータを実装する布石。大きなバッファの送受信を高速化する。
2011-02-27 23:54:26