[英]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.