2

私は、JMS を介して C++ を使用してテキスト メッセージ送信プログラムを作成しました。

tibems_status status = TIBEMS_OK;
status = tibemsMsgProducer_SendToDestination(
                       m_tProducer,
                       m_tDestination,
                       m_tMsg );

status == 0 と仮定すると、これは Function が正常に動作したことのみを意味します。テキスト メッセージが正常に送信されたという意味ではありません。メッセージが正常に送信されたことを確認するにはどうすればよいですか? JMS Queue から ID または確認応答を取得する必要がありますか?

4

1 に答える 1

2

メッセージ配信モードに依存します。

PERSISTENTメッセージが送信されると、呼び出しtibemsMsgProducer_SendToDestinationは EMS サーバーが確認で応答するのを待ちます。

NON_PERSISTENTメッセージが送信されると、承認が有効になっているかどうかと設定に応じて、通話tibemsMsgProducer_SendToDestinationが確認を待機する場合と待機しない場合がありnpsend_check_modeます。具体的な詳細については、EMS ドキュメント (上記のリンク) を参照してください。

最後に、RELIABLE_DELIVERYメッセージが送信されると、tibemsMsgProducer_SendToDestination呼び出しは確認を待たず、EMS サーバーへの接続が失われた場合にのみ失敗します。

ただし、確認が送信された場合でも、これは EMS サーバーがメッセージを受信したことの確認にすぎません。メッセージがメッセージ コンシューマによって受信および処理されたことを確認するものではありません。EMS 監視メッセージを使用して、メッセージがコンシューマーによって確認されたかどうかを判断できます。

メッセージ モニタリング トピックの形式は です$sys.monitor.<D>.<E>.<destination>。matches 、matchesおよび<D>は宛先の名前です。たとえば、 という名前のキューのメッセージ確認を監視するには、プログラムをサブスクライブします(または、確認されたメッセージのコピーが必要な場合)。Q|q|T|t<E>s|r|a|p|\*<destination>beterman$sys.monitor.q.a.beterman$sys.monitor.Q.a.beterman

監視メッセージには、 、 、 などの多くのプロパティが含まmsg_idれsource_nameていますtarget_name。その情報を使用して、送信したメッセージに関連付けることができます。

それ以外の場合、より簡単なオプションは、 のtibemsMsgRequestor代わりにを使用することtibemsMsgProducerです。tibemsMsgRequestor_Requestメッセージを送信し、受信者からの返信を待ちます。この場合、プロデューサと EMS サーバーの間、および EMS サーバーとコンシューマの間のすべての確認メッセージと確認メッセージを使用RELIABLE_DELIVERYして削除するのが最善です。NO_ACKNOWLEDGE

ただし、このtibemsMsgRequestorルートをたどる場合は、EMS サーバーの代わりにロード バランサーを使用して、代わりに単純に HTTP 要求を使用することを検討することもできます。アーキテクチャ的には、2 つのオプションに大きな違いはありません (EMS は永続的な TCP 接続を使用しますが、HTTP は使用しません)。

Producer ->   EMS Server  -> ConsumerA
                          -> ConsumerB

  Client -> Load Balancer -> ServerA
                          -> ServerB

しかし、HTTP を使用すると、各メソッドのセマンティクスが明確になります。GET は安全(状態を変更しない)、PUT と DELETE はべき等(複数の同一の要求は単一の要求と同じ効果を持つべき)、POST は非べき等 (実行されるたびにサーバーの状態が変化する) です。など。ステータス コードも明確に定義されています。を使用しているtibemsMsgRequestor場合は、特注のセマンティクスと応答ステータスを作成する必要があります。これには、チーム内の他の開発者を作成、維持、およびトレーニングするための追加の労力が必要になります。

また、EMS スキルよりも HTTP スキルを持つ開発者を見つける方がはるかに簡単であり、EMS よりも HTTP の方が情報を見つける方がはるかに簡単tibemsMsgRequestorです。

このため、HTTP は、要求と応答の場合、または送信されたメッセージが正常に処理されたことを確認する場合に、より適切なオプションの IMO です。

于 2014-01-16T11:58:53.043 に答える