我在使用DSL时遇到一些问题,因为在Spring Cloud Dataflow上下文中有一个拆分器可以正常运行。基本上我的微服务是一个尝试执行以下操作的处理器:
我想克服的问题是:
验证失败的事件标记有hasError消息头,路由器将其用于将其发送到抛出MessagingException的ServiceActivator。
经过一些调查和实验,我的有缺陷的实验看起来像这样:
IntegrationFlows.from(Processor.INPUT).
// stuff ommitted for brevity
handle(new MyEventPublisher(.........)).
// List of events produced, split them
split().
// validate each event
transform(new MyEventValidator()).
// attempt to circumvent premature stoppage
channel(MessageChannels.executor(Executors.newCachedThreadPool())).
// route events based on validation result
<String>route("headers[hasError] != null && headers[hasError] == 'true'",
spec -> {
spec.resolutionRequired(false);
spec.defaultOutputChannel(Processor.OUTPUT);
// A failed event routes to a service that throws a MessagingException
spec.subFlowMapping("true", sf -> sf.<String>handle(new ExceptionThrowingService()));
// Otherwise events flow onwards
spec.channelMapping("false", Processor.OUTPUT);
}).
get();
如果没有通道步骤和缓存的线程池,则在遇到第一个事件验证失败时,处理将停止,但该失败的事件将被删除,并且任何成功的事件都会通过。
使用线程池处理所有事件。但是,在Dataflow上下文中没有任何事件被删除,因为异常是在执行程序线程中抛出的,但成功的事件确实会引发数据流流。
我是否能够使用拆分器,处理整个输入,并将MessagingExceptions传递给Dataflow运行时?
答案 0 :(得分:0)
Dead Lattering与入站消息有关。确实,只要下游发生任何异常,接收传入消息的容器就会将它(或基于它的东西)发送到DLQ。这已经是您通过拆分器生成许多消息的自定义逻辑,但从Broker的角度来看,它仍然是单个传入消息问题。
要解决此问题,您应该考虑在每个拆分器项验证上手动发送到DLQ。为此,您可以查看ExpressionEvaluatingRequestHandlerAdvice
:http://docs.spring.io/spring-integration/reference/html/messaging-endpoints-chapter.html#expression-advice。并将异常发送到某个通道进行分析。已经在那里你可以发送到DLQ或其他东西。
从Spring Cloud Stream和Data Flow透视图中,您可以为目标添加一个更多绑定配置:http://docs.spring.io/spring-cloud-stream/docs/Chelsea.SR2/reference/htmlsingle/index.html#__code_input_code_and_code_output_code