このバージョンはまだ開発中であり、まだ安定しているとは考えられていません。最新の安定バージョンについては、spring-cloud-stream 4.3.0 を使用してください。

エラーチャネル

バージョン 1.3 以降、バインダーは各コンシューマー宛先のエラーチャネルに無条件に例外を送信し、非同期プロデューサー送信エラーをエラーチャネルに送信するように構成することもできます。詳細については、"エラー処理" を参照してください。

RabbitMQ には、2 種類の送信失敗があります。

後者はまれです。RabbitMQ のドキュメントによると、「[A nack] は、キューを担当する Erlang プロセスで内部エラーが発生した場合にのみ配信されます。」 reject-publish キューオーバーフロー動作を使用して制限付きキューに公開する場合も、否定応答を受け取る可能性があります。

（ "エラー処理" に従って）プロデューサーエラーチャネルを有効にするだけでなく、RabbitMQ バインダーは、接続ファクトリが次のように適切に構成されている場合にのみ、チャネルにメッセージを送信します。

  • ccf.setPublisherConfirms(true);

  • ccf.setPublisherReturns(true);

接続ファクトリに Spring Boot 構成を使用する場合は、次のプロパティを設定します。

  • spring.rabbitmq.publisher-confirms

  • spring.rabbitmq.publisher-returns

返されたメッセージの ErrorMessage のペイロードは、次のプロパティを持つ ReturnedAmqpMessageException です。

  • failedMessage: 送信に失敗した spring-messaging Message<?>。

  • amqpMessage: 生の spring-amqp Message。

  • replyCode: 失敗の理由を示す整数値（たとえば、312- ルートなし）。

  • replyText: 失敗の理由を示すテキスト値（たとえば、NO_ROUTE）。

  • exchange: メッセージが公開された交換。

  • routingKey: メッセージが公開されたときに使用されたルーティングキー。

返されたメッセージを受信するための代替メカニズムについては、パブリッシャーが確認も参照してください。

否定的に確認された確認の場合、ペイロードは次のプロパティを持つ NackedAmqpMessageException です。

  • failedMessage: 送信に失敗した spring-messaging Message<?>。

  • nackReason: 理由（利用可能な場合 - 詳細については、ブローカーのログを調べる必要がある場合があります）。

これらの例外（デッドレターキューへの送信など）の自動処理はありません。これらの例外は、独自の Spring Integration フローで使用できます。