問題タブ [dead-letter]

現在、依存性注入に scaldi を使用して Akka ルーター ロジックを実装するのに苦労しています。私のアクターはルーターであり、そのインスタンスを 1 つだけ持ちたいのに、scaldi を使用して単一のアクター インスタンスにバインドできないのはなぜですか? 私がこの質問をするようになった方法は、別のスタックオーバーフロー エントリでした。

私のスカルディモジュール:

この方法では、1 つのインスタンスのみが作成され、ルーターに複数回注入するとすぐに、sender() メソッドから送信者としてデッド レター アクターが取得されます。

バインディングを次のように変更すると...

...完全に正常に動作しますが、すべての注入はルーターの新しいインスタンスを意味します。私は正しいですか？

では、注入可能なルーターのインスタンスを 1 つだけ持つにはどうすればよいでしょうか?

前もって感謝します

次のように、交換にバインドされたキューがあります。

このキューに、デッド レター交換を次のようにバインドしました。

次のように、デッド レター キューをデッド レター交換にバインドしました。

また、配信不能キューは次のように宣言されています。

しかし、normal_queue詳細を調べると、次のパラメーターのみが表示されます。

デッドレター交換をここにリストする必要がありますか? これはデッドレター交換が正しく設定されていないということですか?

2 つのキューと x-dead-letter-exchange/x-message-ttl を使用して遅延メッセージ処理を実装しました。キュー 1 でメッセージがタイムアウトした後、キュー 2 に移動します。

キュー 2 からのメッセージの処理中に「デッドレター」として拒否した場合、キュー 3 に自動的に移動するように RabbitMQ をセットアップすることはできますか? 私の懸念は、queue2 のメッセージが既に「dead」とマークされていることです。拒否されたために死んでいるメッセージを区別し、それらのみを自動的に queue3 に入れる方法はありますか?

メッセージをデッド レター チャネル (この場合は activemq キュー) に送信する前にメッセージを数回再試行する errorHandler を Camel ルートに設定しました。私が望むのは、メッセージが最大回数の再試行に失敗し、デッド レター キューに送信されたときにエラー ログを表示することです。

エラー処理とデッド レター チャネルのドキュメントを見ると、RedeliveryPolicy には retriesAttemptedLogLevel と retriesExhaustedLogLevel の 2 つのオプションがあるようです。デフォルトでは、retriesExhaustedLogLevel はすでに LoggingLevel.ERROR に設定されていると思われますが、すべての再試行を使い果たし、メッセージをデッド レター チャネルにルーティングすると、実際には何もログに記録されないようです。

これは、Java DSL による私の errorHandler 定義です。

レベルを明示的に ERROR に設定しましたが、まだ何もログアウトしていないようです (どのログ レベルにも)。一方、retryAttemptedLogLevel は問題なく機能しており、適切な LoggingLevel にログを記録します (つまり、retryAttemptedLogLevel を LoggingLevel.ERROR に設定し、再試行を ERROR ログとして表示できます)。ただし、後続の再試行が成功する可能性がある場合は、再試行ごとに ERROR ログではなく、枯渇した場合に 1 つの ERROR ログのみが必要です。

多分私は何かが欠けているかもしれませんが、retriesExhaustedLogLevel は何もしないようです...または、ErrorHandler が DeadLetterChannel として構成されている場合は何もログに記録しません。まだ必要な構成はありますか、それとも RedeliveryPolicy のこの機能はこの特定の ErrorHandlerFactory に対して実行されませんか?

また、使い果たされたメッセージを送信するためのルートを設定することもできます。これは単にログに記録してデッド レター チャネルにルーティングするだけですが、可能であれば、ErrorHandler に既に組み込まれているものを試して使用することをお勧めします。

JBoss 7.1 で Java アプリケーションを実行しています。20 を超える JMS キューを使用しています。

JMS キューをセットアップするための私の構成:

ここで、上記の 2 つのキューのデッド レター キューを構成したいと考えています。マッチにはどのような値を使用する必要がありますか?

#はすべての JMS キューに適用されるため使用できませんが、必要なのは 2 つだけです。

また、メッセージをデッドレターキューから元のキューにプッシュバックする方法はありますか?

hornet キュー バージョン 2.2.13 を使用しており、ワイルド カードを として使用したいと考えていますMX.EQ.*.*.OUT。*文字の間にまたはを入れる#と、サーバーは起動中に例外をスローします。

Azure ServiceBus 監視システムとして ServiceInsight を実装しています。
エラー キューからメッセージを再送信できることは知っていますが、デッド レター キューにあるメッセージを再送信することはできますか?

1 つ以上の永続的なサブスクリプションを持つ jms トピックがあります。あるサブスクライバーがロールバックを引き起こし、別のサブスクライバーが成功する状況があります。メッセージは配信不能アドレスに到着します。

バグを解決してメッセージを続行できるようになったら、メッセージを元の宛先 (トピック) に戻したいと考えています。問題は、それを行った後、失敗したものだけでなく、すべてのサブスクライバーがメッセージを受け取ることです。

どうにか解決することは可能でしょうか？

情報だけです。JBoss eap 6.1 と HornetQ を jms プロバイダーとして使用しています。

SQS を使用してジョブをキューに入れるアプリがあります。理想的には、すべてのジョブを完了したいのですが、失敗するものもあります。それらを再実行するとうまくいく場合もあれば、保持期間に達するまで失敗し続ける場合もあります。. 失敗したジョブをできるだけ長くキューに入れておき、成功の可能性を最大限に高めたいので、maxReceiveCount. MessageRetentionPeriodただし、ジョブが完全に失敗したときにアラートを送信する必要があるため、ジョブが制限に達したことを検出したいと考えています。現在、最大保持期間は 14 日間ですが、一部のジョブはそれまでに完了しません。

ジョブの有効期限が近づいていることを検出し、そこからデッドレター キューに送信して追加の処理を行う方法はありますか?