問題タブ [activemq-artemis]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
jakarta-ee - デッド レター キューの JMSXDeliveryCount
メッセージがデッド レター キューに到達した後に、メッセージの実際の再配信数を取得する方法を教えてください。出現、アルテミスはこれを新しい配信と見なし、カウンターを 1 にリセットします。
以下の図を参照してください。 1. メッセージは MDB によって消費されます。2.何か問題が発生し、再試行の最大回数が 3 回に達するまで、コンテキストで setRollbackOnly を呼び出します。3. Artemis は設定された DLQ にメッセージを送信します。4. DLQ Mdb はメッセージを消費しますが、メッセージの JMSXDeliveryCount は3ではなく 1 を読み取ります。
DLQ から再試行回数 3 を取得する方法はありますか?
java - ActiveMQ トピックでの並列メッセージ消費
サブスクライバーでアクティブにできるコンシューマーは 1 つだけであることが、ActiveMQ の永続的なトピックのようです (これが JMS 自体の障害になっているようです)。
つまり、ActiveMQ ドキュメントでは次のようになります。
JMS 永続サブスクライバ MessageConsumer は、一意の JMS クライアント ID と永続サブスクライバ名で作成されます。JMS に準拠するためには、1 つの JMS クライアント ID に対してアクティブにできる JMS 接続は常に 1 つだけであり、クライアント ID とサブスクライバー名に対してアクティブにできるコンシューマーは 1 つだけです。つまり、特定の論理トピック サブスクライバーからアクティブに使用できるスレッドは 1 つだけです。
ただし、他のキュー システム (ドキュメントに基づいて、Azure Service Bus がこれを行うように見えます) では、単一の「サブスクリプション」で複数のスレッド化された「サブスクライバー」を簡単に許可するようです。今の時代、それは当然のことだと思うでしょう。
これはなぜですか？これは、JMS や ActiveMQ の将来のバージョンで解決される予定ですか?
PS「仮想トピック」(上記のドキュメント) は、サブスクライバーごとにバックグラウンドで完全に個別のキューを作成するように見えるため、このシナリオではあまり理想的ではなく、パフォーマンスも低い回避策のようです。