大した話ではなくきわめて単純な非EJBでの手作りメッセージングの話。この場合P2PでもPub/Subでも良いが、プッシュモデルである以上、配送元に設定が必要である。システムが発展すると、第2、第3の配送先が必要になる可能性がある。この時、配送元は既に安定稼動しているのだから、いっさい変化を与えたくはない(H/W増強とかはもちろん別の話となる)。第2、第3の配送先にのみ、何かをすればすぐに配送元に繋がるという状態が望ましい。ある意味において一元管理はしたくないということだ。新規に追加されたもののみ変更したい(というか設定したい)ということ。この場合、P2Pは最初から土俵に上がることさえできない。Pub/Subの場合はどうだろうか?設定としてあらかじめ配送先を配送元に記述する方法は最初の要求から問題外だ。配送リクエストをネゴするという方法は取り得る。この場合、配送元はプッシュする前に配信先のポートを知ることができるからだ。ネゴの過程で配送デーモンを1つ相手に貼り付ける。後の動作はP2Pとして実行しても良い。この場合の問題点はめんどうだということだ。めんどうなソフトウェアはバグの混入率が大抵の場合上がってしまう。配送デーモンが消滅することの監視も必要となる。(スレッドではなくプロセスにすれば多少監視しやすい)ネットワークを使う場合、キープアライブを流すのを避けたり無通信検出タイマーの間隔が長いとこの状態が発生してしまう。(よく考えたらP2Pでも動揺だ)(配送先が消滅したら配送元の送信エラーで発見できる)ネゴの問題点はもう1つ、タイミングである。配送先がネゴしようとしたら配送元がたまたまメンテ中だったから無応答。この場合、配送先に適切なリトライのロジックが必要となる。これもめんどうのうちだ。これらについてポールが解決策となりうるのはわかり切っている。この場合の考慮点は、1.メッセージの抜け対策2.配送先の突然死(誰も気付かない)3.ポールの間隔の3点。1.は配送先毎のキューを使わないことから簡単に発生しうる。配送先が独自のシーケンス管理(キュー—と言っても1本しかないし、配送先複数が前提なので誰もデキューできない。したがって、単純にはDBMS上のテーブルとして配送元は何も考えずにインサートし配送先が勝手に読み取るというのが現実的だ)たとえば、配送元はSEQUENCEを使ってキュー(っていうかインサート)していく。障害が発生すればSEQUNECEは飛ぶから必ずしも1繰り上がるわけではない。いうようには単純化できない。発生順の維持は当然必要だ。current);でなければならない。(が、これはこれだけのことだ)このようにして得たデータ(というよりも現在のSEQの値)を配送元は独自に管理する。QUEUEを実行し、配送先プロセスのログと突合せをして一致していなければ怒る(怒る前に数秒待って、配送先の受信済みSEQが変化しなければ本気で怒るとすべき。なければたまたま遅延しているだけかも知れない。したがって、ここでの数秒というのは、ポールの間隔よりは長い必要がある)というような防御が必要となる。配送先監視のいずれのプログラムも非常に単純に実装できる。問題は、結局、3.として残るポールによる負荷(空読みのくせに、MIN(SEQ)とかが必要となるため、必ずしも効率的ではない)だ。#配送元のQUEUEテーブルへのインサートが複数のプロセスによりランダムに行われるとSEQUENCEのロックがあってもポールの微妙な間隔で飛ぶ可能性があることも注意点となる。insertと必ずしもならないからだ。プロセス/スレッドスィッチがinsertの呼び出し未満で発生するとまずい(追記:バカなことを書いている。insert時点では次のシーケンスを得ているんだから全く問題ではない)。微妙な感じがしないでもない)。言うか発生順が重要なら順序維持は必須か。