简体   繁体   English

Spring Cloud Stream rabbitmq binder - Spring Cloud 函数错误处理

[英]Spring cloud stream rabbitmq binder - spring cloud function error handling

i am using spring cloud stream rabbit binder with spring cloud function and defining listeners like:我正在使用具有 spring cloud 功能的 spring cloud stream rabbit binder 并定义如下侦听器:

public Function<Flux<SomeObject>, Flux<OtherObject>> foo() {
//some code
}

I also reroute failed messages to DLQ.我还将失败的消息重新路由到 DLQ。 Problem is when fatal error like org.springframework.messaging.converter.MessageConversionException happens.问题是当像org.springframework.messaging.converter.MessageConversionException这样的致命错误发生时。 It does not get processed by ConditionalRejectingErrorHandler like mentioned in https://docs.spring.io/spring-amqp/reference/html/#exception-handling , and keeps cycling forever.它不会像https://docs.spring.io/spring-amqp/reference/html/#exception-handling 中提到的那样被ConditionalRejectingErrorHandler处理,并且永远循环。

Is there a way to make this work with ConditionalRejectingErrorHandler ?有没有办法用ConditionalRejectingErrorHandler使这个工作?

Right now i fix the problem by using @ServiceActivator(inputChannel = "errorChannel") and handling the errors myself.现在我通过使用@ServiceActivator(inputChannel = "errorChannel")并自己处理错误来解决问题。

Dependencies:依赖项:

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.2.4.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
</parent>
<dependencies>
        <dependency>
            <groupId>org.springframework.boot.experimental</groupId>
            <artifactId>spring-boot-starter-data-r2dbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-webflux</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-consul-config</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-stream</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-hateoas</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-web</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-stream-binder-rabbit</artifactId>
        </dependency>
</dependencies>

We've long debated error handling and other features that we use for imperative functions and how they apply (or can they even be applied) to reactive functions and tried few different things, but unfortunately it all comes down to impedance mismatch.我们长期以来一直在争论我们用于命令式函数的错误处理和其他功能,以及它们如何应用(或者甚至可以应用)到反应式函数,并尝试了一些不同的事情,但不幸的是,这一切都归结为阻抗不匹配。

The approaches you are describing are based on the operating on a single Message.您所描述的方法基于对单个消息的操作。 That is the unit of work within the imperative style message handlers such as Function<String, String> .这是必要的样式消息处理程序内工作,例如单位Function<String, String> You use reactive style and by doing so changed the unit of work from a single message in the stream to the entire stream.您使用反应式风格,并通过这样做将工作单元从流中的单个消息更改为整个流。

In short:简而言之:

- Function<?, ?> - unit of work is Message
- Function<Flux<?>, Flux<?>> - unit of work is the entire stream

You can also observe it easily as reactive function is only invoked once for the duration of the life of the application while imperative is invoked once per each arriving message.您还可以很容易地观察到它,因为响应式函数在应用程序的生命周期内仅被调用一次,而每个到达的消息都会调用一次命令式函数。 The reason why I am saying that is that the framework-based approaches we use for imperative message handlers (functions) can not be applied to reactive without causing side-effects.我这么说的原因是我们用于命令式消息处理程序(函数)的基于框架的方法不能应用于反应式而不引起副作用。 And generally reactive developers understand this especially given the richness of the reactive API specifically with regard to error handling考虑到响应式 API 的丰富性,特别是在错误处理方面,响应式开发人员通常理解这一点

In any event, we'll update documentation accordingly.无论如何,我们将相应地更新文档。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 使用 Spring Cloud Stream Kafka Binder 时 Kafka Producer 中的错误处理 - Error Handling in Kafka Producer while using Spring Cloud Stream Kafka Binder Spring 云 Stream 与 RabbitMQ 连接 - Spring Cloud Stream connection with RabbitMQ Spring 云 stream - RabbitMQ 配置 - Spring cloud stream - RabbitMQ configuration 如何配置 spring boot 以使用 spring-cloud-stream 和 rabbit-binder 将供应商绑定到 rabbitmq 队列? - How to configure spring boot to bind a supplier to a rabbitmq queue with spring-cloud-stream and rabbit-binder? 如何处理 Spring 云 stream kafka 流活页夹中的序列化错误? - How to handle Serialization error in Spring cloud stream kafka streams binder? 子进程中的Spring Cloud Stream Kinesis绑定器错误 - Spring Cloud Stream Kinesis binder error in child process Spring Cloud Stream Service-Bus Binder 的错误通道 - Error channel for Spring Cloud Stream Service-Bus Binder Spring Cloud Stream Kinesis活页夹-并发 - Spring Cloud Stream Kinesis Binder - Concurrency Spring Cloud 流 artemis 绑定器并发不起作用 - Spring cloud stream artemis binder concurrency not working 春天云流 - gcp pubsub binder maxFetchSize? - spring cloud stream - gcp pubsub binder maxFetchSize?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM