ブローカーの構成
AMQP 仕様では、プロトコルを使用してブローカーでキュー、交換、バインディングを構成する方法が説明されています。これらの操作 (0.8 仕様以降から移植可能) は、org.springframework.amqp.core
パッケージの AmqpAdmin
インターフェースに存在します。そのクラスの RabbitMQ 実装は、org.springframework.amqp.rabbit.core
パッケージにある RabbitAdmin
です。
AmqpAdmin
インターフェースは、Spring AMQP ドメイン抽象化の使用に基づいており、次のリストに示されています。
public interface AmqpAdmin {
// Exchange Operations
void declareExchange(Exchange exchange);
void deleteExchange(String exchangeName);
// Queue Operations
Queue declareQueue();
String declareQueue(Queue queue);
void deleteQueue(String queueName);
void deleteQueue(String queueName, boolean unused, boolean empty);
void purgeQueue(String queueName, boolean noWait);
// Binding Operations
void declareBinding(Binding binding);
void removeBinding(Binding binding);
Properties getQueueProperties(String queueName);
}
範囲指定された操作も参照してください。
getQueueProperties()
メソッドは、キューに関する限定的な情報 (メッセージ数とコンシューマー数) を返します。返されるプロパティのキーは、RabbitAdmin
(QUEUE_NAME
、QUEUE_MESSAGE_COUNT
、QUEUE_CONSUMER_COUNT
) で定数として使用できます。RabbitMQ REST API は、QueueInfo
オブジェクトでより多くの情報を提供します。
引数なしの declareQueue()
メソッドは、自動的に生成される名前でブローカーにキューを定義します。この自動生成されたキューの追加のプロパティは exclusive=true
、autoDelete=true
、durable=false
です。
declareQueue(Queue queue)
メソッドは Queue
オブジェクトを受け取り、宣言されたキューの名前を返します。指定された Queue
の name
プロパティが空の String
である場合、ブローカは生成された名前でキューを宣言します。その名前が呼び出し元に返されます。その名前は、Queue
の actualName
プロパティにも追加されます。この機能をプログラムで使用するには、RabbitAdmin
を直接呼び出す必要があります。アプリケーションコンテキストでキューを宣言的に定義するときに管理者による自動宣言を使用する場合、name プロパティを ""
(空の文字列) に設定できます。次に、ブローカーが名前を作成します。バージョン 2.1 以降、リスナーコンテナーはこの型のキューを使用できます。詳細については、コンテナーとブローカー名のキューを参照してください。
これは、フレームワークが一意の (UUID
) 名を生成し、durable
を false
に、exclusive
を autoDelete
を true
に設定する AnonymousQueue
とは対照的です。空の (または欠落している) name
属性を持つ <rabbit:queue/>
は、常に AnonymousQueue
を作成します。
AnonymousQueue
を参照して、ブローカーが生成したキュー名よりも AnonymousQueue
が優先される理由と、名前の形式を制御する方法を理解しましょう。バージョン 2.1 以降、匿名キューは、デフォルトで client-local
に設定された引数 Queue.X_QUEUE_LEADER_LOCATOR
で宣言されます。これにより、アプリケーションが接続されているノードでキューが宣言されます。宣言型キューは、次の例に示すリスナーなど、コンテキスト内の他の場所で参照される可能性があるため、固定の名前を付ける必要があります。
<rabbit:listener-container>
<rabbit:listener ref="listener" queue-names="#{someQueue.name}" />
</rabbit:listener-container>
交換、キュー、バインディングの自動宣言を参照してください。
このインターフェースの RabbitMQ 実装は RabbitAdmin
であり、Spring XML を使用して構成すると、次の例のようになります。
<rabbit:connection-factory id="connectionFactory"/>
<rabbit:admin id="amqpAdmin" connection-factory="connectionFactory"/>
CachingConnectionFactory
キャッシュモードが CHANNEL
(デフォルト) の場合、RabbitAdmin
実装は、同じ ApplicationContext
で宣言されたキュー、交換、バインディングの自動遅延宣言を行います。これらのコンポーネントは、ブローカーに対して Connection
が開かれるとすぐに宣言されます。これを非常に便利にする名前空間機能がいくつかあります。たとえば、Stocks サンプルアプリケーションには次の機能があります。
<rabbit:queue id="tradeQueue"/>
<rabbit:queue id="marketDataQueue"/>
<fanout-exchange name="broadcast.responses"
xmlns="http://www.springframework.org/schema/rabbit">
<bindings>
<binding queue="tradeQueue"/>
</bindings>
</fanout-exchange>
<topic-exchange name="app.stock.marketdata"
xmlns="http://www.springframework.org/schema/rabbit">
<bindings>
<binding queue="marketDataQueue" pattern="${stocks.quote.pattern}"/>
</bindings>
</topic-exchange>
前の例では、匿名キュー (実際には、内部では、ブローカーではなくフレームワークによって生成された名前を持つキューのみ) を使用し、ID で参照しています。また、明示的な名前でキューを宣言することもできます。これは、コンテキスト内の Bean 定義の識別子としても機能します。次の例では、明示的な名前でキューを構成します。
<rabbit:queue name="stocks.trade.queue"/>
id 属性と name 属性の両方を指定できます。これにより、キュー名とは独立した ID でキューを参照できます (たとえば、バインディング内)。また、標準の Spring 機能 (プロパティプレースホルダーやキュー名の SpEL 式など) も使用できます。名前を Bean 識別子として使用する場合、これらの機能は使用できません。 |
キューは追加の引数 (たとえば、x-message-ttl
) を使用して構成できます。名前空間サポートを使用する場合、<rabbit:queue-arguments>
要素を使用して定義される argument-name/argument-value ペアの Map
の形式で提供されます。次の例は、その方法を示しています。
<rabbit:queue name="withArguments">
<rabbit:queue-arguments>
<entry key="x-dead-letter-exchange" value="myDLX"/>
<entry key="x-dead-letter-routing-key" value="dlqRK"/>
</rabbit:queue-arguments>
</rabbit:queue>
デフォルトでは、引数は文字列であると想定されます。他の型の引数については、型を指定する必要があります。次の例は、型を指定する方法を示しています。
<rabbit:queue name="withArguments">
<rabbit:queue-arguments value-type="java.lang.Long">
<entry key="x-message-ttl" value="100"/>
</rabbit:queue-arguments>
</rabbit:queue>
型が混在する引数を指定する場合は、エントリ要素ごとに型を指定する必要があります。次の例は、その方法を示しています。
<rabbit:queue name="withArguments">
<rabbit:queue-arguments>
<entry key="x-message-ttl">
<value type="java.lang.Long">100</value>
</entry>
<entry key="x-dead-letter-exchange" value="myDLX"/>
<entry key="x-dead-letter-routing-key" value="dlqRK"/>
</rabbit:queue-arguments>
</rabbit:queue>
Spring Framework 3.2 以降では、次のようにもう少し簡潔に宣言できます。
<rabbit:queue name="withArguments">
<rabbit:queue-arguments>
<entry key="x-message-ttl" value="100" value-type="java.lang.Long"/>
<entry key="x-ha-policy" value="all"/>
</rabbit:queue-arguments>
</rabbit:queue>
Java 構成を使用する場合、Queue.X_QUEUE_LEADER_LOCATOR
引数は、Queue
クラスの setLeaderLocator()
メソッドを介してファーストクラスプロパティとしてサポートされます。バージョン 2.1 以降、匿名キューは、このプロパティがデフォルトで client-local
に設定されて宣言されます。これにより、アプリケーションが接続されているノードでキューが宣言されます。
RabbitMQ ブローカーは、引数が一致しないキューの宣言を許可しません。例: queue が time to live 引数なしですでに存在し、(たとえば) key="x-message-ttl" value="100" で宣言しようとすると、例外がスローされます。 |
デフォルトでは、例外が発生すると、RabbitAdmin
はすべての宣言の処理を即座に停止します。これにより、別のキュー (エラーが発生したキューの後に定義されたキュー) が宣言されていないためにリスナーコンテナーが初期化に失敗するなど、ダウンストリームの問題が発生する可能性があります。
この動作は、RabbitAdmin
インスタンスで ignore-declaration-exceptions
属性を true
に設定することで変更できます。このオプションは、例外をログに記録し、他の要素の宣言を続行するように RabbitAdmin
に指示します。Java を使用して RabbitAdmin
を構成する場合、このプロパティは ignoreDeclarationExceptions
と呼ばれます。これは、すべての要素に適用されるグローバル設定です。キュー、エクスチェンジ、バインディングには、それらの要素だけに適用される同様のプロパティがあります。
バージョン 1.6 より前のバージョンでは、このプロパティは、チャネルで IOException
が発生した場合 (現在のプロパティと必要なプロパティが一致しない場合など) にのみ有効でした。現在、このプロパティは、TimeoutException
などを含むすべての例外で有効です。
さらに、宣言の例外により、コンテキスト内の任意の ApplicationListener
で使用できる ApplicationEvent
である DeclarationExceptionEvent
が発行されます。イベントには、admin、宣言されていた要素、Throwable
への参照が含まれています。
ヘッダー交換
バージョン 1.3 以降では、HeadersExchange
を複数のヘッダーで一致するように構成できます。一部またはすべてのヘッダーが一致する必要があるかどうかを指定することもできます。次の例は、その方法を示しています。
<rabbit:headers-exchange name="headers-test">
<rabbit:bindings>
<rabbit:binding queue="bucket">
<rabbit:binding-arguments>
<entry key="foo" value="bar"/>
<entry key="baz" value="qux"/>
<entry key="x-match" value="all"/>
</rabbit:binding-arguments>
</rabbit:binding>
</rabbit:bindings>
</rabbit:headers-exchange>
バージョン 1.6 以降では、internal
フラグ (デフォルトは false
) を使用して Exchanges
を構成でき、そのような Exchange
は RabbitAdmin
を介してブローカーで適切に構成されます (アプリケーションコンテキストに存在する場合)。交換の internal
フラグが true
の場合、RabbitMQ はクライアントに交換を使用させません。これは、発行者が交換を直接使用したくないデッドレター交換または交換間バインディングに役立ちます。
Java を使用して AMQP インフラストラクチャを構成する方法を確認するには、Stock サンプルアプリケーションを参照してください。ここには @Configuration
クラス AbstractStockRabbitConfiguration
があり、これには RabbitClientConfiguration
および RabbitServerConfiguration
サブクラスがあります。次のリストは、AbstractStockRabbitConfiguration
のコードを示しています。
@Configuration
public abstract class AbstractStockAppRabbitConfiguration {
@Bean
public CachingConnectionFactory connectionFactory() {
CachingConnectionFactory connectionFactory =
new CachingConnectionFactory("localhost");
connectionFactory.setUsername("guest");
connectionFactory.setPassword("guest");
return connectionFactory;
}
@Bean
public RabbitTemplate rabbitTemplate() {
RabbitTemplate template = new RabbitTemplate(connectionFactory());
template.setMessageConverter(jsonMessageConverter());
configureRabbitTemplate(template);
return template;
}
@Bean
public Jackson2JsonMessageConverter jsonMessageConverter() {
return new Jackson2JsonMessageConverter();
}
@Bean
public TopicExchange marketDataExchange() {
return new TopicExchange("app.stock.marketdata");
}
// additional code omitted for brevity
}
Stock アプリケーションでは、サーバーは次の @Configuration
クラスを使用して構成されます。
@Configuration
public class RabbitServerConfiguration extends AbstractStockAppRabbitConfiguration {
@Bean
public Queue stockRequestQueue() {
return new Queue("app.stock.request");
}
}
これで、@Configuration
クラスの継承 チェーン全体が終了します。最終的に、TopicExchange
と Queue
は、アプリケーションの起動時にブローカーに宣言されます。クライアントアプリケーションで行われるような、サーバー構成でのキューへの TopicExchange
のバインドはありません。ただし、在庫リクエストキューは AMQP デフォルト取引所に自動的にバインドされます。この動作は仕様で定義されています。
クライアント @Configuration
クラスはもう少し興味深いものです。その宣言は次のとおりです。
@Configuration
public class RabbitClientConfiguration extends AbstractStockAppRabbitConfiguration {
@Value("${stocks.quote.pattern}")
private String marketDataRoutingKey;
@Bean
public Queue marketDataQueue() {
return amqpAdmin().declareQueue();
}
/**
* Binds to the market data exchange.
* Interested in any stock quotes
* that match its routing key.
*/
@Bean
public Binding marketDataBinding() {
return BindingBuilder.bind(
marketDataQueue()).to(marketDataExchange()).with(marketDataRoutingKey);
}
// additional code omitted for brevity
}
クライアントは、AmqpAdmin
で declareQueue()
メソッドを介して別のキューを宣言します。プロパティファイルで外部化されたルーティングパターンを使用して、そのキューをマーケットプレースデータ交換にバインドします。
キューとエクスチェンジのビルダー API
バージョン 1.6 では、Java 構成を使用するときに Queue
および Exchange
オブジェクトを構成するための便利な流れるような API が導入されています。次の例は、その使用方法を示しています。
@Bean
public Queue queue() {
return QueueBuilder.nonDurable("foo")
.autoDelete()
.exclusive()
.withArgument("foo", "bar")
.build();
}
@Bean
public Exchange exchange() {
return ExchangeBuilder.directExchange("foo")
.autoDelete()
.internal()
.withArgument("foo", "bar")
.build();
}
詳細については、org.springframework.amqp.core.QueueBuilder
(Javadoc) および org.springframework.amqp.core.ExchangeBuilder
(Javadoc) の Javadoc を参照してください。
バージョン 2.0 以降、ExchangeBuilder
は、個々の AbstractExchange
クラスの単純なコンストラクターと一貫性を保つために、デフォルトで永続的な交換を作成するようになりました。ビルダーとの非永続的な交換を行うには、.build()
を呼び出す前に .durable(false)
を使用します。パラメーターのない durable()
メソッドは提供されなくなりました。
バージョン 2.2 では流れるような API が導入され、「よく知られている」交換とキューの引数が追加されました…
@Bean
public Queue allArgs1() {
return QueueBuilder.nonDurable("all.args.1")
.ttl(1000)
.expires(200_000)
.maxLength(42)
.maxLengthBytes(10_000)
.overflow(Overflow.rejectPublish)
.deadLetterExchange("dlx")
.deadLetterRoutingKey("dlrk")
.maxPriority(4)
.lazy()
.leaderLocator(LeaderLocator.minLeaders)
.singleActiveConsumer()
.build();
}
@Bean
public DirectExchange ex() {
return ExchangeBuilder.directExchange("ex.with.alternate")
.durable(true)
.alternate("alternate")
.build();
}
交換、キュー、バインディングのコレクションの宣言
Declarable
オブジェクト (Queue
、Exchange
、Binding
) のコレクションを Declarables
オブジェクトでラップできます。RabbitAdmin
は、アプリケーションコンテキストでそのような Bean (および個別の Declarable
Bean) を検出し、接続が確立されるたびに (最初と接続障害の後)、ブローカーで含まれているオブジェクトを宣言します。次の例は、その方法を示しています。
@Configuration
public static class Config {
@Bean
public CachingConnectionFactory cf() {
return new CachingConnectionFactory("localhost");
}
@Bean
public RabbitAdmin admin(ConnectionFactory cf) {
return new RabbitAdmin(cf);
}
@Bean
public DirectExchange e1() {
return new DirectExchange("e1", false, true);
}
@Bean
public Queue q1() {
return new Queue("q1", false, false, true);
}
@Bean
public Binding b1() {
return BindingBuilder.bind(q1()).to(e1()).with("k1");
}
@Bean
public Declarables es() {
return new Declarables(
new DirectExchange("e2", false, true),
new DirectExchange("e3", false, true));
}
@Bean
public Declarables qs() {
return new Declarables(
new Queue("q2", false, false, true),
new Queue("q3", false, false, true));
}
@Bean
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public Declarables prototypes() {
return new Declarables(new Queue(this.prototypeQueueName, false, false, true));
}
@Bean
public Declarables bs() {
return new Declarables(
new Binding("q2", DestinationType.QUEUE, "e2", "k2", null),
new Binding("q3", DestinationType.QUEUE, "e3", "k3", null));
}
@Bean
public Declarables ds() {
return new Declarables(
new DirectExchange("e4", false, true),
new Queue("q4", false, false, true),
new Binding("q4", DestinationType.QUEUE, "e4", "k4", null));
}
}
2.1 より前のバージョンでは、型 Collection<Declarable> の Bean を定義することにより、複数の Declarable インスタンスを宣言できました。管理者はすべての Collection<?> Bean を反復処理する必要があるため、これは場合によっては望ましくない副作用を引き起こす可能性があります。 |
バージョン 2.2 は getDeclarablesByType
メソッドを Declarables
に追加しました。これは、リスナーコンテナー Bean(s) を宣言する場合などに便利に使用できます。
public SimpleMessageListenerContainer container(ConnectionFactory connectionFactory,
Declarables mixedDeclarables, MessageListener listener) {
SimpleMessageListenerContainer container = new SimpleMessageListenerContainer(connectionFactory);
container.setQueues(mixedDeclarables.getDeclarablesByType(Queue.class).toArray(new Queue[0]));
container.setMessageListener(listener);
return container;
}
条件宣言
デフォルトでは、すべてのキュー、エクスチェンジ、バインディングは、アプリケーションコンテキスト内のすべての RabbitAdmin
インスタンス (それらに auto-startup="true"
があると仮定) によって宣言されます。
バージョン 2.1.9 以降、RabbitAdmin
には新しいプロパティ explicitDeclarationsOnly
(デフォルトでは false
) があります。これが true
に設定されている場合、管理者は、その管理者によって宣言されるように明示的に構成されている Bean のみを宣言します。
1.2 リリース以降、これらの要素を条件付きで宣言できます。これは、アプリケーションが複数のブローカーに接続し、特定の要素を宣言する必要があるブローカーを指定する必要がある場合に特に役立ちます。 |
これらの要素を表すクラスは、shouldDeclare()
と getDeclaringAdmins()
の 2 つのメソッドを持つ Declarable
を実装します。RabbitAdmin
はこれらのメソッドを使用して、特定のインスタンスがその Connection
の宣言を実際に処理する必要があるかどうかを判断します。
次の例に示すように、プロパティは名前空間の属性として使用できます。
<rabbit:admin id="admin1" connection-factory="CF1" />
<rabbit:admin id="admin2" connection-factory="CF2" />
<rabbit:admin id="admin3" connection-factory="CF3" explicit-declarations-only="true" />
<rabbit:queue id="declaredByAdmin1AndAdmin2Implicitly" />
<rabbit:queue id="declaredByAdmin1AndAdmin2" declared-by="admin1, admin2" />
<rabbit:queue id="declaredByAdmin1Only" declared-by="admin1" />
<rabbit:queue id="notDeclaredByAllExceptAdmin3" auto-declare="false" />
<rabbit:direct-exchange name="direct" declared-by="admin1, admin2">
<rabbit:bindings>
<rabbit:binding key="foo" queue="bar"/>
</rabbit:bindings>
</rabbit:direct-exchange>
デフォルトでは、auto-declare 属性は true であり、declared-by が指定されていない (または空である) 場合、すべての RabbitAdmin インスタンスがオブジェクトを宣言します (管理者の auto-startup 属性がデフォルトの true であり、管理者の explicit-declarations-only 属性が false である限り))。 |
同様に、Java ベースの @Configuration
を使用して同じ効果を得ることができます。次の例では、コンポーネントは admin1
で宣言されていますが、admin2
では宣言されていません。
@Bean
public RabbitAdmin admin1() {
return new RabbitAdmin(cf1());
}
@Bean
public RabbitAdmin admin2() {
return new RabbitAdmin(cf2());
}
@Bean
public Queue queue() {
Queue queue = new Queue("foo");
queue.setAdminsThatShouldDeclare(admin1());
return queue;
}
@Bean
public Exchange exchange() {
DirectExchange exchange = new DirectExchange("bar");
exchange.setAdminsThatShouldDeclare(admin1());
return exchange;
}
@Bean
public Binding binding() {
Binding binding = new Binding("foo", DestinationType.QUEUE, exchange().getName(), "foo", null);
binding.setAdminsThatShouldDeclare(admin1());
return binding;
}
id
および name
属性に関する注意
<rabbit:queue/>
および <rabbit:exchange/>
要素の name
属性は、ブローカー内のエンティティの名前を反映します。キューの場合、name
を省略すると、匿名キューが作成されます ( AnonymousQueue
を参照)。
2.0 より前のバージョンでは、name
は Bean の別名としても登録されていました (<bean/>
要素の name
と同様)。
これにより、次の 2 つの問題が発生しました。
同じ名前のキューと交換の宣言を防ぎました。
SpEL 式 (
#{…}
) が含まれている場合、エイリアスは解決されませんでした。
バージョン 2.0 以降、これらの要素の 1 つを id
属性と name
属性の両方で宣言すると、その名前は Bean 名の別名として宣言されなくなりました。キューを宣言して同じ name
と交換したい場合は、id
を提供する必要があります。
エレメントに name
属性しかない場合は変更されません。Bean は、バインディング宣言などで name
によって引き続き参照できます。ただし、名前に SpEL が含まれている場合は参照できません。参照用に id
を指定する必要があります。
AnonymousQueue
一般に、一意の名前の排他的な自動削除キューが必要な場合は、ブローカ定義のキュー名の代わりに AnonymousQueue
を使用することをお勧めします (""
を Queue
名として使用すると、ブローカがキュー名を生成します)。
それの訳は:
ブローカへの接続が確立されると、キューは実際に宣言されます。これは、Bean が作成されて相互に接続されてからずっと後のことです。キューを使用する Bean は、その名前を知る必要があります。実際、アプリケーションの開始時にブローカーが実行されていない場合もあります。
ブローカーへの接続が何らかの理由で失われた場合、管理者は同じ名前で
AnonymousQueue
を再宣言します。ブローカーによって宣言されたキューを使用すると、キュー名が変更されます。
AnonymousQueue
インスタンスで使用されるキュー名の形式を制御できます。
デフォルトでは、キュー名の前に spring.gen-
が付けられ、その後に UUID
の base64 表現が続きます (例: spring.gen-MRBv9sqISkuCiPfOYfpo4g
)。
コンストラクター引数で AnonymousQueue.NamingStrategy
実装を提供できます。次の例は、その方法を示しています。
@Bean
public Queue anon1() {
return new AnonymousQueue();
}
@Bean
public Queue anon2() {
return new AnonymousQueue(new AnonymousQueue.Base64UrlNamingStrategy("something-"));
}
@Bean
public Queue anon3() {
return new AnonymousQueue(AnonymousQueue.UUIDNamingStrategy.DEFAULT);
}
最初の Bean は、spring.gen-
で始まり、その後に UUID
の base64 表現が続くキュー名を生成します (例: spring.gen-MRBv9sqISkuCiPfOYfpo4g
)。2 番目の Bean は、something-
で始まり、その後に UUID
の base64 表現が続くキュー名を生成します。3 番目の Bean は、UUID のみ (base64 変換なし) を使用して名前を生成します (例: f20c818a-006b-4416-bf91-643590fedb0e
)。
base64 エンコーディングでは、RFC 4648 の「URL およびファイル名のセーフアルファベット」が使用されます。末尾の埋め込み文字 (=
) は削除されます。
キュー名に他の情報 (アプリケーション名やクライアントホストなど) を含めることができる独自の命名戦略を提供できます。
XML 構成を使用する場合、命名戦略を指定できます。naming-strategy
属性は、AnonymousQueue.NamingStrategy
を実装する Bean 参照の <rabbit:queue>
要素に存在します。次の例は、さまざまな方法で命名戦略を指定する方法を示しています。
<rabbit:queue id="uuidAnon" />
<rabbit:queue id="springAnon" naming-strategy="uuidNamer" />
<rabbit:queue id="customAnon" naming-strategy="customNamer" />
<bean id="uuidNamer" class="org.springframework.amqp.core.AnonymousQueue.UUIDNamingStrategy" />
<bean id="customNamer" class="org.springframework.amqp.core.AnonymousQueue.Base64UrlNamingStrategy">
<constructor-arg value="custom.gen-" />
</bean>
最初の例では、spring.gen-MRBv9sqISkuCiPfOYfpo4g
などの名前を作成します。2 番目の例では、UUID の文字列表現で名前を作成します。3 番目の例では、custom.gen-MRBv9sqISkuCiPfOYfpo4g
などの名前を作成します。
独自の命名戦略 Bean を提供することもできます。
バージョン 2.1 以降、匿名キューは、デフォルトで client-local
に設定された引数 Queue.X_QUEUE_LEADER_LOCATOR
で宣言されます。これにより、アプリケーションが接続されているノードでキューが宣言されます。インスタンスの構築後に queue.setLeaderLocator(null)
を呼び出すことで、以前の動作に戻すことができます。
自動削除宣言の回復
通常、RabbitAdmin
は、アプリケーションコンテキストで Bean として宣言されているキュー / エクスチェンジ / バインディングのみを回復します。そのような宣言が自動削除されている場合、接続が失われるとブローカーによって削除されます。接続が再確立されると、管理者はエンティティを再宣言します。通常、admin.declareQueue(…)
、admin.declareExchange(…)
、admin.declareBinding(…)
を呼び出して作成されたエンティティは復元されません。
バージョン 2.4 以降、管理者には新しいプロパティ redeclareManualDeclarations
があります。true
の場合、管理者はアプリケーションコンテキストの Bean に加えてこれらのエンティティを回復します。
deleteQueue(…)
、deleteExchange(…)
または removeBinding(…)
が呼び出された場合、個々の宣言のリカバリは実行されません。キューと交換が削除されると、関連付けられたバインディングは回復可能なエンティティから削除されます。
最後に、resetAllManualDeclarations()
を呼び出すと、以前に宣言されたエンティティの回復が妨げられます。