HTTPリクエストをリッスンするSpring Integrationを使用してHTTPエンドポイントを実装し、要求データをメッセージとしてチャネルに送信し、別のエンドポイントがこのチャネルのメッセージをリスンして処理する必要があります。Spring Integrationポーリングなしの待ち行列でlistenする
簡単な音です。しかし、私が達成したいのは次のとおりです。
- メッセージは順番に処理する必要があります。
- メッセージは早急に処理する必要があります(キューがすでに空の場合は、http要求後に遅延なし)。
- httpリクエストは、メッセージが受信されるとすぐに応答され、処理された後ではないため、処理のためにそのメッセージのみが受信されます。
- 私はRabbitMQのような外部キューを使いたくありません。
ですので、これにはQueueChannel
が必要です。しかし、正しく理解すれば、キューからメッセージを受信する唯一の方法はpoller
です。したがって、ポイント2は満たされません。メッセージが受信された後、ポーラーがそれを見る前に少し遅れるでしょう。
質問があります:Spring Integrationでこれを達成するための簡単な方法はありますか?
もちろん私はそれを自分で実装することができます。たとえば、SmartLifeCycle
コンポーネントを作成します。これは、DirectChannel
をリッスンし、メッセージをjava.util.concurrent.BlockingQueue
に入れるだけです。また、このキューで待機して別のDirectChannel
にメッセージを送信する専用スレッドを開始します。したがって、BlockingQueue
が空でないとすぐにスレッドがブロック解除されるため、遅延はありません。
これはすべて「パターン」のように聞こえます。専用のスレッドに基づく2つのダイレクトチャネル間のキューです。
おそらくSpring Integrationで既に実装されている単純な方法がありますが、これはこの領域にはexpirienceがないため表示されません。
ありがとう、ゲーリー!私は 'receiveTimeout'が実際には時間であることを知らなかった。ポーラーのスレッドはスケジューラーのスレッドを解放するまでバッキング' BlockingQueue'で新しいメッセージを待つだろう。そしてその後、ポーラーの 'Trigger'(例えば' delay')に従ってスレッドを再び占有します。したがって、 '1s'の' 0'と 'receiveTimeout'の遅れで、ポーラーはスケジューラーのスレッドをほとんどいつもブロックし、メッセージをできるだけ早く処理します!どうもありがとうございます! * P.S。エグゼキュータの内部キューを使用するシングルスレッドエグゼキュータを使用したエグゼキュータチャネルも、私が考えなかった実行可能なソリューションです! – djxak
これらのオプションのいずれかが、サーバクラッシュ時にメッセージの損失を招く可能性があることに注意してください。アプリケーションに問題がある場合は、永続的なストア(rabbitmqなど)を使用する必要があります。 –
はい、私はこれを知っています。しかし、メッセージはRabbitMqを使用していても失われる可能性があります。呼び出し元と受信HTTPエンドポイント間のネットワーク接続、メッセージが受信された後、RabbitMqのキューに送信される前のアプリケーションクラッシュ、呼び出し元のクラッシュ。したがって、外部キューを使用するのではなく(少なくとも1回は必ず)、外部ソースからの最後のX分間のすべてのメッセージの定期的なフェッチをスケジュールし、それらを無作為に進める方がよいでしょう。おそらく失われたメッセージを処理するためのある種の「代償性フェッチャー」。 – djxak