2016-04-01 11 views
1

ActiveMQをメッセージのブローカーとして使用して簡単なチャットアプリケーションをセットアップしました。チャットは、両方の当事者がメッセージを発行し、両方の当事者がメッセージを購読できるトピックです。メッセージには、送信者IDや受信者IDのような、メッセージに関するいくつかのメタデータが含まれています。それはすべて正常に動作します。ActiveMQの購読済みおよび未送信のトピックメッセージの数

チャットメッセージを待っているすべてのユーザー、つまりオフラインになっていて、読まれるのを待っているトピックの公開メッセージがあります。これらのユーザーは、新しいメッセージを読むことについての別のプラットフォームを使用して(モバイルに)通知を受け取る必要があります。

すべてのActiveMQのドキュメントとフォーラムで回答を検索しましたが、何も見つかりませんでした(理解していない可能性があります)。これは、MQが処理するための明白なクエリのようです...

ブローカのI'vが有効になっており、EnqueueCount/DequeueCountが見つかりましたが、送信されたメッセージの合計数すべての加入者)。

答えて

1

どのメッセージが公開され、どのメッセージが消費された(消費されていない)のかを知るためにできることは、advisory messagesを聞くことができます。

「管理アプリ」からActiveMQ.Advisory.MessageDelivered.Topicを購読して、配信されたメッセージを確認してください。

ActiveMQ.Advisory.MessageConsumed.Topicにサブスクライブして、どのメッセージが消費されているか調べてください。

次に、時間枠内で消費されていないメッセージがあり、何らかのアクションを取る必要がある(他の方法でユーザーに通知する)場合は、多少の作業で可能性があります。

この設定を有効にする必要があります。

<destinationPolicy> 
    <policyMap><policyEntries> 
     <policyEntry topic=">" advisoryForConsumed="true" /> 
    </policyEntries></policyMap> 
</destinationPolicy> 
+0

ありがとう、ちょうどうまくいくかもしれません。私は、助言メッセージの内容を詳しく見なければならないでしょう...後で報告するでしょう。 – karpy47

+0

ここに私のレポートです...私は代わりに新しい問題に遭遇しました。 MQTTをトランスポート・プロトコルとして使用しています。これは、アドバイザリ・メッセージ(少なくともActiveMQとすべてのテストについては理解できていないからです)で動作しないことが判明しました。私はアプリケーションの再設計を終え、メッセージに関するメタデータを公開するいくつかのトピックを追加しました。勧告メッセージの仕組みと同様に、私は推測します。 – karpy47

+0

このアイデアは実用的な解決策に導いてくれたので、これを私の答えと記しました。しかし、それはあなたのために働くかもしれないので、また、マットパブロビッチの答えをお読みください。 – karpy47

2

恒久サブスクリプションを調べます。これにより、ブローカはどのユーザがどのメッセージを受信したかを把握し、「一時停止」問題をサポートする各ユーザのサブスクリプションを作成します。

追加クレジット:代わりに仮想トピックを使用してください。それはトピックに公開されています - >キューの意味論から購読します。柔軟性が増し、保守が容易になります。

注:

  1. プロデューサー先::トピック://My.Topic
  2. 購読1つの宛先名:キュー:コンフィグサンプル

    <broker...> 
    .... <!-- be sure to place elements after "<broker>" in alphabetical order --> 
    <destinationInterceptors> 
         <virtualDestinationInterceptor> 
          <virtualDestinations> 
          <virtualTopic name=">" prefix="VirtualTopicConsumers.*." selectorAware="false"/> 
         </virtualDestinations> 
        </virtualDestinationInterceptor> 
    </destinationInterceptors> 
    ... 
    </broker> 
    

    のために編集がその後に自分のプロデューサーを設定//VirtualTopicConsumers.Sub1.My.Topic

  3. サブスクリプション1宛先名:キュー://仮想トピックスコンスマーズ。サブ。マイトピックス
+0

ありがとうございます。永続的なサブスクリプションの考え方にはほとんど従ってはいけません。定期的なトピックは、送信者と受信者の時間差を解決するうえで効果的です。仮想トピックは複数のスレッドから消費されているようですが、トピックの残りのメッセージに関する情報はどのように取得できますか? – karpy47

+0

恒久サブスクリプションは、消費を待っているメッセージ数のメトリックを維持します。さらに、VirtualTopicアプローチでキューを使用すると、サブスクライバ単位で消費されるメッセージの残量を示すキュー統計を使用することができます –

+0

私が使用している永続的なサブスクリプションに関する私の最初の混乱については申し訳ありません既に。あなたの仮想トピック待ち行列の考え方はうまくいくかもしれませんが、私はActiveMQ文書を読むだけでは頭を抱かせることができませんでした。 Petter Nordlanderが提案した助言メッセージのアプローチは、私にとっては簡単でした。 – karpy47

関連する問題