5

これは、永続的なサブスクリプションを作成するコンテキストにあります。
DefaultMessageListenerContainerに setClientId() があり、SingleConnectionFactory にもう 1 つ存在します。

私の理解は次のとおりです。

  • 永続サブスクリプションは、コンシューマー/サブスクライバー向けです。
  • 異なるコンシューマーは、異なるクライアント ID を使用できる必要があります。
  • 異なるコンシューマが接続を共有できる必要があります。
  • コンシューマごとに 1 つの (ListenerContainer,Listener) ペアがあります。

したがって、ListenerContainer で setClientId() を使用することは理にかなっています。

しかし、接続ファクトリ レベルで setClientId() があるのはなぜですか?

SingleConnectionFactory には単一の接続しかありませんが、その接続は、複数のセッションにわたって複数のコンシューマーによって共有される可能性があります。右 ？言うまでもなく、(SingleConnectionFactory からこのメソッドを継承する) CachingConnectionFactory の場合はより危険です。

拡張バージョン: Single/CachingConnectionFactory で setClientId() を使用すべきではないと言えますか? これは、DefaultMessageListenerContainer の setClientId() 内の次のステートメントによってさらに必須になります。

さらに、元の ConnectionFactory がまだクライアント ID を割り当てていない場合にのみ、クライアント ID を割り当てることができます。

そのため、誰かが CachingConnectionFactory で誤って ClientId を設定した場合、DefaultMessageListenerContainer のクライアント ID の今後のセットは no-ops になります。

4

1 に答える 1

4

しかし、接続ファクトリ レベルで setClientId() があるのはなぜですか?

setClientId()接続ファクトリでは、クライアント ID を管理的に設定するために使用され、コンシューマー アプリケーションが手動で設定するのを防ぎます。実際、JMS 仕様によると、クライアント ID がファクトリによって既に設定されている場合に、クライアント ID がクライアントによって設定されると、例外がスローされます。

Single/CachingConnectionFactory で setClientId() を使用すべきではないと言えますか?

それぞれ独自のクライアント ID を持つ異なるサブスクライバーに対して永続的なサブスクリプションを作成する必要がある場合は、を使用します。クライアント ID が既に設定されている同じファクトリから複数の接続をsubscriber.setClientId()使用して作成しようとすると、ファクトリは「接続clientIdは既に接続されています。」connectionFactory.setClientId()

個人的には、コードの柔軟性と完全な制御が好きなので、subscriber.setClientId()

于 2013-06-17T21:04:41.267 に答える