jakarta-ee - MDBと耐久性

Question

耐久性を理解するために、MDBがデプロイされているアプリサーバーをJMSプロバイダー（サーバー）から分離して、アプリサーバーがシャットダウンして後で再起動した場合に、MDBに送信されたメッセージを送信できるようにする必要があります。アプリサーバーがダウンしている間に逃した？

Answer 1

しかし、サーバーがメッセージを受け入れなかった場合（メッセージもダウンしていたため）、クライアントはすべてが正常であるとは考えられないため、不思議なことにメッセージが失われることはありません。

ただし、実際には、耐久性プロパティは、複数のリモートクライアントがリッスンしている単一のトピックを想定しています。トピックに対して異なるリモートサーバー上に複数のリスナーがすでに存在するような設定の場合、この質問をすることはないと思います。したがって、MDBがすべて単一のサーバーにデプロイされていると仮定します。

その場合、JMSプロバイダーを分離すると、このプロバイダーだけを実行しているサーバーのクラッシュのリスクが低くなり（特に独自のコードがない場合は、専用システムが小さくなり、クラッシュする可能性が低くなります）、バッファーとして機能する可能性があるため、堅牢性が向上する可能性があります。アプリケーションサーバーを再起動する必要がある状況の場合。一方、サーバーごとに、少なくとも1つのサーバーがクラッシュする可能性が高くなり、どこかで構成エラーが発生する可能性も高くなります。これは、自分で作成する必要があるトレードオフです。

Answer 2

はいと思います。1つのオプションは、HornetQをスタンドアロンでデプロイすることです。

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/architecture.html#d0e636

このように、フル機能のJBossサーバーをデプロイする必要がなく、ホストの仕様を減らすことでコストを節約できます。スタンドアロンモードでのHornetQのメモリフットプリントは非常に低くなる可能性があります。

jmsブローカーとMDBクライアントを分割するオプションがない場合、私がかつて行った方法は、未送信のメッセージを保持するキャッシュをクライアントに開発することでした。サーバーがダウンした場合、JBossが再びアップするまでメッセージを保存します。

Answer 3

耐久性プロパティは、サーバーのトピックがメッセージを受け入れたためにクライアントがすべて問題ないと考える状況を対象としていますが、1つ以上の受信者がダウンしているため、意図したすべての受信者に実際に配信することはできません。

しかし、サーバーがメッセージを受け入れなかった場合（メッセージもダウンしていたため）、クライアントはすべてが正常であるとは考えられないため、不思議なことにメッセージが失われることはありません。

ただし、実際には、耐久性プロパティは、複数のリモートクライアントがリッスンしている単一のトピックを想定しています。トピックに対して異なるリモートサーバー上に複数のリスナーがすでに存在するような設定の場合、この質問をすることはないと思います。したがって、MDBがすべて単一のサーバーにデプロイされていると仮定します。

その場合、JMSプロバイダーを分離すると、このプロバイダーだけを実行しているサーバーのクラッシュのリスクが低くなり（特に独自のコードがない場合は、専用システムが小さくなり、クラッシュする可能性が低くなります）、バッファーとして機能する可能性があるため、堅牢性が向上する可能性があります。アプリケーションサーバーを再起動する必要がある状況の場合。一方、サーバーごとに、少なくとも1つのサーバーがクラッシュする可能性が高くなり、どこかで構成エラーが発生する可能性も高くなります。これは、自分で作成する必要があるトレードオフです。