ブローカーの構成

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_NAMEQUEUE_MESSAGE_COUNTQUEUE_CONSUMER_COUNT) で定数として使用できます。RabbitMQ REST API は、QueueInfo オブジェクトでより多くの情報を提供します。

引数なしの declareQueue() メソッドは、自動的に生成される名前でブローカーにキューを定義します。この自動生成されたキューの追加のプロパティは exclusive=trueautoDelete=truedurable=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 オブジェクト (QueueExchangeBinding) のコレクションを 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 名として使用すると、ブローカがキュー名を生成します)。

それの訳は:

  1. ブローカへの接続が確立されると、キューは実際に宣言されます。これは、Bean が作成されて相互に接続されてからずっと後のことです。キューを使用する Bean は、その名前を知る必要があります。実際、アプリケーションの開始時にブローカーが実行されていない場合もあります。

  2. ブローカーへの接続が何らかの理由で失われた場合、管理者は同じ名前で 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() を呼び出すと、以前に宣言されたエンティティの回復が妨げられます。