0

私は、バックエンド処理のために NIO サーバーからメッセージ キューに作業をオフロードする利点を探るために設計された概念実証プロジェクトに取り組んでいます。私は NIO ボイラープレートに Grizzly を使用し、メッセージングには Spring Integration (メッセージング実装として JMS/ActiveMQ を使用) を使用しています。基本的に、私がやりたいことはこれです:

クライアント接続 -> サーバー -> サーバーが「作業完了」メッセージを作成 -> JMS/ActiveMQ

ActiveMQ メッセージ キューでは、多数の「ワーカー」がこれらのメッセージをアクティブに消費し、処理して、結果を別のキューに配置します。サーバーはそのキューで「応答メッセージ」をリッスンしており、メッセージが取得されると、次のように実行されます。

応答キュー -> サーバーはメッセージをクライアントが理解できるものにシリアル化します -> クライアントに戻します

私の差し迫った問題は、Grizzly、特にイベント処理をメッセージングから切り離す方法を理解していないことです。サーバーは、応答メッセージがワーカーから返されたときに、サーバーがクライアントが誰であるかを認識できるように (Grizzly で関連する FilterChainContext を見つけて)、tcp を送信するために作業メッセージを作成する必要があります。メッセージ。

FilterChainContext.getAddress() を使用してそれを作業メッセージに配置できるかもしれませんが、ピアアドレスとメッセージを受け取り、何らかの方法でそれを送信するメソッド (FilterChainContext.write()) をコーディングする方法がわかりません。 FilterChainContext はありません。

私は今、マップを保持するという考えで遊んでいますが、シリアライゼーションまたは処理中にメッセージに何かが起こった場合にマップ内のものを古くしたくないので、このアプローチについて心配しています。

アイデアや提案は大歓迎です。

-マイケル

4

1 に答える 1

0

カスタム(デ)シリアライザーと一緒に、TCPアダプター/ゲートウェイ(NIOを使用するオプションがあります)を使用できます。Grizzly を使用する必要がある場合は、サーバー接続ファクトリーの実装を作成できます。送信アダプター (または受信ゲートウェイ) の場合、エンドポイントは (connectionId を使用して) 'TcpListener' として登録され、SI メッセージにはIpHeaders.CONNECTION_ID、応答を取得する接続を決定するために使用されるヘッダーが含まれます。接続が閉じると、登録が解除されます (マップから削除されます)。

于 2013-01-28T13:54:11.253 に答える