0
2つのJMSキューの間にミドルウェアがあります。 1つは読み取り、データベースにはいくつかのデータを処理し、もう1つはデータを書き込みます。遅延処理のためにJMSでメッセージをキューイング
はここで設計描くための小さな図である。このことを念頭に置いて
を、私は私がサービスに統合したいと思い、いくつかの興味深いロジックを持っています。
シナリオ1：ミドルウェアサービスは、キュー1からのメッセージを受信し、そのメッセージの部分を格納するデータベースを打つと言います。すべてうまくいくと、いくつかのデータを含む新しいメッセージが作成され、キュー2に書き込まれます。
シナリオ2：メッセージを取得した後にサービスが何らかのロジックを実行しようとすると、この場合、キュー2にメッセージを書き込む代わりに、増分タイムアウトでデータベース機能を再試行します。すなわち、5秒後に再度、次に30秒後に、次に1秒後にもう一度試してください。キャッチはもちろん、この再試行とは別に他のメッセージを読むことができるようにすることです。すなわち、この1つのリクエストを処理して、他のリクエストをリスンします。念頭に置いて
、将来性ソリューションを構築するための正しいと最も近代的な方法の両方は何ですか？
ネット上のいくつかの記事を読んだあと、いくつかの選択肢があるようです。
- 新しいメッセージが受信されると、新しいスレッドをスピンオフすることができます。そのため、「再試行」機能を実行して新しい要求を聞くことができます。
- 2つ目は、メッセージをキューに遅れて返信する可能性があります。すなわち、プロセスがdb内で実行されなかった場合は、それにいくらかの遅延を追加してメッセージをJMSキューに書き込みます。
私は最初の解決策がもっと好きですが、私はJava 7でこの機能を解決するためのより新しい/良い方法があれば、コミュニティの意見を得たいと思っています。この種の「特定の時間に再処理のためにメッセージを送り返す」をサポートしていますか？
配信タイミングが保証されないという単純な理由から、JMSに遅延配信の概念があるとは思われません。 JMSが提供する唯一の保証は、メッセージが最終的に配信されることです。だから、メッセージのタイミングやシーケンスを保証することはできません... –
@GermannArlingtonうーん、私は参照してください。私はスレッドしなければならないと思う。 – angryip