エラーの取扱いと復旧
http://rubyamqp.info/articles/error_handling/ の和訳。脚注は訳者による。 エラーの取扱いと復旧このガイドについて送信側であれ受信側であれ、多岐に渡る異常系をどうエレガントに扱うかが、AMQPと関わりのあるアプリケーションを頑健にしていくうえでは不可避と言えましょう。プロトコルの誤り、ネットワークの不調、ブローカー1の異常などが思い浮かぶことでしょう。これらを正しく処理して上手に正常状態に回復することは、容易ではないでしょう。以下では、amqp gemを使うことでアプリケーションが ブローカーとの接続ができなかったときネットワークが切断されたときAMQPコネクションに例外2が発生したときAMQPチャンネル3に例外が発生したときブローカーの異常に遭遇したときTLS(SSL)関連の障害があったときのような状況をどのように切り抜けることができるか、のみ
あえて言うがRuby会議はそろそろ一回終わってみるべき。
表題のようなことを実は2007年のやつの後くらいから思ってて、今年はほとんど確信に近くなっている。Ruby会議2009最終日にうっかり角谷さんの電波(自称)を浴びてしまったせいで、当日は「あー、俺より角谷さんのほうがちゃんと考えてて、でも逃げてないんだなあ」とか思った。思ったが、一日たって冷静に考えてみたら、やっぱ逃げてもいいと思うよ。なので当初考えていたとおりに書くことにする。 (1) おまえらの仕事は品質過剰です。 Ruby会議は世間のカンファレンスの相場から考えると、クオリティに比して参加費が異常に安い。クオリティの高さに関しては素晴らしいとは思うが、それの費用は安すぎだと思う。 なぜRuby会議はあのクオリティで開催できるのか、一回きちんと考察してみるべきだ。俺には参加費の代わりにおまえらのモチベーションを削ぎ落としながら燃料にしてオペレーション回してるようにしか見えない。横から見
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
