I'm testing my existent application with a new spring-integration version. Unfortunately, I'm getting a unexpected exception, like below:
Caused by: java.lang.UnsupportedOperationException: null
at org.springframework.integration.dsl.StandardIntegrationFlow.configure(StandardIntegrationFlow.java:64) ~[spring-integration-java-dsl-1.2.1.RELEASE.jar:na]
at org.springframework.integration.dsl.IntegrationFlowDefinition.wireTap(IntegrationFlowDefinition.java:341) ~[spring-integration-java-dsl-1.2.1.RELEASE.jar:na]
at org.springframework.integration.dsl.IntegrationFlowDefinition.wireTap(IntegrationFlowDefinition.java:276) ~[spring-integration-java-dsl-1.2.1.RELEASE.jar:na]
at com.smartplan.maiscontrole.config.ReportGenerationFlowConfig.buildFlow(ReportGenerationFlowConfig.java:49) ~[main/:na]
My code, actually looks like:
#Override
protected IntegrationFlowDefinition<?> buildFlow() {
return this.from(this.requestChannel())
.wireTap(this.sideEffectFlow())
.channel(new NullChannel());
}
#Bean
MessageChannel requestChannel() {
return MessageChannels.direct();
}
#Bean
IntegrationFlow sideEffectFlow() {
return f -> f.handle(System.out::println);
}
Any clue about this?
M-m-m, I think it's really UnsupportedOperationException.
Try to remove #Bean from that sideEffectFlow.
Nested flows can't be beans. Or connect them via channels.
Related
I have following spring integration flow:
#Bean
public IntegrationFlow innerInFlow(#Value("${jms.concurrency:10}") String concurrency) {
return IntegrationFlows
.from(Jms.messageDrivenChannelAdapter(
Jms.container(connectionFactory, innerQueue)
.concurrency(concurrency)
.taskExecutor(taskExecutor()).get())
.extractPayload(true))
.transform(Transformers.deserializer())
.route(eventRouter())
.get();
}
And after routing
#Bean
public IntegrationFlow findPersonClienFlow(FindClientHandler findClientHandler) {
return IntegrationFlows.from(findPersonClienChannel())
.transform(findClientHandler, "queryToFindClientRequest")
.handle(Jms.outboundGateway(connectionFactory).requestDestination(cifRequestQueue)
.replyDestination(cifResponseQueue).get())
.get();
}
}
In the Jms.outboundGateway I have org.springframework.integration.MessageTimeoutException and I cant understand how I can handle this error?
Thank you.
I believe the MessageTimeoutException is there because the other side doesn't send you a reply into the cifResponseQueue.
You can configure there a receiveTimeout(), but it is 5 secs by default anyway.
Also you can configure a RequestHandlerRetryAdvice or ExpressionEvaluatingRequestHandlerAdvice on this Jms.outboundGateway() to really handle this exception some specific way, using an advice(...) of the ConsumerEndpointSpec.
See Docs on the matter: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints-chapter.html#message-handler-advice-chain
UPDATE
Also as Gary pointed you can catch an exception from the Jms.messageDrivenChannelAdapter() level using its errorChannel() and some flow subscribed to this channel.
I'm working on a service which sends emails using the spring integration java dsl.
I have a batch message which is split into a collection of individual messages which will be turned into emails.
The issue I am experiencing is that if one of these individual messages throws an error, the other messages in the batch are not processed.
Is there a way to configure the flow so that when a message throws an exception, the exception is handled gracefully and the next message in the batch is processed?
The following code achieves the functionality I would like but I'm wondering if there is an easier / better way to achieve this, ideally in a single IntegrationFlow? :
#Bean
public MessageChannel individualFlowInputChannel() {
return MessageChannels.direct().get();
}
#Bean
public IntegrationFlow batchFlow() {
return f -> f
.split()
.handle(message -> {
try {
individualFlowInputChannel().send(message);
} catch (Exception e) {
e.printStackTrace();
}
});
}
#Bean
public IntegrationFlow individualFlow() {
return IntegrationFlows.from(individualFlowInputChannel())
.handle((payload, headers) -> {
throw new RuntimeException("BOOM!");
}).get();
}
You can add ExpressionEvaluatingRequestHandlerAdvice to the last handle() definition with its trapException option:
/**
* If true, any exception will be caught and null returned.
* Default false.
* #param trapException true to trap Exceptions.
*/
public void setTrapException(boolean trapException) {
On the other hand, if you are talking about "sends emails", wouldn't it be better to consider to do that in the separate thread for each splitted item? In this case the ExecutorChannel after .split() comes to the rescue!
After upgrading the above jar files, I keep running into the issue below:
org.springframework.beans.factory.BeanCreationException: The
'currentComponent'
(org.springframework.integration.router.MethodInvokingRouter#5ddcc487)
is a one-way 'MessageHandler' and it isn't appropriate to configure
'outputChannel'. This is the end of the integration flow. at
org.springframework.integration.dsl.IntegrationFlowDefinition.registerOutputChannelIfCan(IntegrationFlowDefinition.java:3053)
at
org.springframework.integration.dsl.IntegrationFlowDefinition.register(IntegrationFlowDefinition.java:2994)
at
org.springframework.integration.dsl.IntegrationFlowDefinition.handle(IntegrationFlowDefinition.java:1167)
at
org.springframework.integration.dsl.IntegrationFlowDefinition.handle(IntegrationFlowDefinition.java:987)
at
org.springframework.integration.dsl.IntegrationFlowDefinition.handle(IntegrationFlowDefinition.java:964)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Code Snippet:
public IntegrationFlow inBoundFlow(ConnectionFactory mqConnection)
throws JMSException {
return IntegrationFlows
.from(Jms.messageDrivenChannelAdapter(mqConnection)
.configureListenerContainer(listenerContainer)
.destination(mqProperties.getQueue().getRequest())
.errorChannel(ErrorChannel())
.setHeaderMapper(new DefaultJmsHeaderMapper()))
.filter(filterMessage, "filterMessage", m -> m.discardChannel(DiscardChannel()))
.route(mqMessageRouter, "messageRouter")
.handle(errorChannel, "handleError")
.get();
}
#Named
public class MQErrorMessageChannel {
#ServiceActivator(inputChannel = MQ_ERROR_MESSAGE_INPUT_CHANNEL, outputChannel = MQ_ERROR_MESSAGE_OUTPUT_CHANNEL)
public Message<String> handleError(Throwable t) {
//Do Something....
}
return null;
}
}
Any pointer?
The .route(mqMessageRouter, "messageRouter") in this form of method invocation is exactly one-way and you can't point anything after that in the flow.
There is no strict decision which channel will be next after router, so we can't continue the flow from there.
Just divide your flow to several and add that .handle() there to each particular routed flow.
I am using Spring Integration DSL and have a simple Gateway:
#MessagingGateway(name = "eventGateway", defaultRequestChannel = "inputChannel")
public interface EventProcessorGateway {
#Gateway(requestChannel="inputChannel")
public void processEvent(Message message)
}
My spring integration flow is defined as:
#Bean MessageChannel inputChannel() { return new DirectChannel(); }
#Bean MessageChannel errorChannel() { return new DirectChannel(); }
#Bean MessageChannel retryGatewayChannel() { return new DirectChannel(); }
#Bean MessageChannel jsonChannel() { return new DirectChannel(); }
#Bean
public IntegrationFlow postEvents() {
return IntegrationFlows.from(inputChannel())
.route("headers.contentType", m -> m.channelMapping(MediaType.APPLICATION_JSON_VALUE, "json")
)
.get();
}
#Bean
public IntegrationFlow retryGateway() {
return IntegrationFlows.from("json")
.gateway(retryGatewayChannel(), e -> e.advice(retryAdvice()))
.get();
}
#Bean
public IntegrationFlow transformJsonEvents() {
return IntegrationFlows
.from(retryGatewayChannel())
.transform(new JsonTransformer())
.handle(new JsonHandler())
.get();
}
The JsonTransformer is a simple AbstractTransformer that transforms the JSON data and passes it to the JsonHandler.
class JsonHandler extends AbstractMessageHandler {
public void handleMessageInternal(Message message) throws Exception {
// do stuff, return nothing if success else throw Exception
}
}
I call my gateway from code as such:
try {
Message<List<EventRecord>> message = MessageBuilder.createMessage(eventList, new MessageHeaders(['contentType': contentType]))
eventProcessorGateway.processEvent(message)
logSuccess(eventList)
} catch (Exception e) {
logError(eventList)
}
I want the entire call and processing to be synchronous, and any errors that occur to be caught so I can handle them appropriately. The call to the gateway works, the message gets sent to through the Transformer and to the Handler, processed and if an Exception occurs it bubbles back and is caught and logError() is called. However if the call is successful, the call to logSuccess() never occurs. It is like execution stops/hangs after the Handler processes the message and never returns. I do not need to actually get any response, I am more concerned if something fails to process. Do I need to send something back to the initial EventProcessorGateway?
Your issue is here:
return IntegrationFlows.from("json")
.gateway(retryGatewayChannel(), e -> e.advice(retryAdvice()))
.get();
where that .gateway() is request/reply because it is a part of the main flow.
It is something similar to the <gateway> within <chain>.
So, even if your main flow is one-way, using .gateway() inside that requires from your sub-flow some reply, but this one:
.handle(new JsonHandler())
.get();
doesn't do that.
Because it is one-way MessageHandler.
From other side, even if you'd make the last one as request-reply (AbstractReplyProducingMessageHandler), it won't help you because you don't know what to do with that reply after the mid-flow gateway. Just because your main flow is the one-way.
You must re-think your desing a bit more and try to get rid of that mid-flow gateway. I see that you try to make some logic with retryAdvice().
But how about to move it to the .handle(new JsonHandler()) instead of that wrong .gateway()?
I am trying to implement the following using Spring Integration with DSL and lambda:
Given a message, send it to N consumers (via publish-subscribe). Wait for limited time and return all results that have arrived form consumers (<= N) during that interval.
Here is an example configuration I have so far:
#Configuration
#EnableIntegration
#IntegrationComponentScan
#ComponentScan
public class ExampleConfiguration {
#Bean(name = PollerMetadata.DEFAULT_POLLER)
public PollerMetadata poller() {
return Pollers.fixedRate(1000).maxMessagesPerPoll(1).get();
}
#Bean
public MessageChannel publishSubscribeChannel() {
return MessageChannels.publishSubscribe(splitterExecutorService()).applySequence(true).get();
}
#Bean
public ThreadPoolTaskExecutor splitterExecutorService() {
final ThreadPoolTaskExecutor executorService = new ThreadPoolTaskExecutor();
executorService.setCorePoolSize(3);
executorService.setMaxPoolSize(10);
return executorService;
}
#Bean
public DirectChannel errorChannel() {
return new DirectChannel();
}
#Bean
public DirectChannel requestChannel() {
return new DirectChannel();
}
#Bean
public DirectChannel channel1() {
return new DirectChannel();
}
#Bean
public DirectChannel channel2() {
return new DirectChannel();
}
#Bean
public DirectChannel collectorChannel() {
return new DirectChannel();
}
#Bean
public TransformerChannel1 transformerChannel1() {
return new TransformerChannel1();
}
#Bean
public TransformerChannel2 transformerChannel2() {
return new TransformerChannel2();
}
#Bean
public IntegrationFlow errorFlow() {
return IntegrationFlows.from(errorChannel())
.handle(m -> System.err.println("[" + Thread.currentThread().getName() + "] " + m.getPayload()))
.get();
}
#Bean
public IntegrationFlow channel1Flow() {
return IntegrationFlows.from(publishSubscribeChannel())
.transform("1: "::concat)
.transform(transformerChannel1())
.channel(collectorChannel())
.get();
}
#Bean
public IntegrationFlow channel2Flow() {
return IntegrationFlows.from(publishSubscribeChannel())
.transform("2: "::concat)
.transform(transformerChannel2())
.channel(collectorChannel())
.get();
}
#Bean
public IntegrationFlow splitterFlow() {
return IntegrationFlows.from(requestChannel())
.channel(publishSubscribeChannel())
.get();
}
#Bean
public IntegrationFlow collectorFlow() {
return IntegrationFlows.from(collectorChannel())
.resequence(r -> r.releasePartialSequences(true),
null)
.aggregate(a ->
a.sendPartialResultOnExpiry(true)
.groupTimeout(500)
, null)
.get();
}
}
TransformerChannel1 and TransformerChannel2 are sample consumers and have been implemented with just a sleep to emulate delay.
The message flow is:
splitterFlow -> channel1Flow \
-> channel2Flow / -> collectorFlow
Everything seem to work as expected, but I see warnings like:
Reply message received but the receiving thread has already received a reply
which is to be expected, given that partial result was returned.
Questions:
Overall, is this a good approach?
What is the right way to gracefully service or discard those delayed messages?
How to deal with exceptions? Ideally I'd like to send them to errorChannel, but am not sure where to specify this.
Yes, the solution looks good. I guess it fits for the Scatter-Gather pattern. The implementation is provided since version 4.1.
From other side there is on more option for the aggregator since that version, too - expire-groups-upon-timeout, which is true for the aggregator by default. With this option as false you will be able to achieve your requirement to discard all those late messages. Unfortunately DSL doesn't support it yet. Hence it won't help even if you upgrade your project to use Spring Integration 4.1.
Another option for those "Reply message received but the receiving thread has already received a reply" is on the spring.integraton.messagingTemplate.throwExceptionOnLateReply = true option using spring.integration.properties file within the META-INF of one of jar.
Anyway I think that Scatter-Gather is the best solution for you use-case.
You can find here how to configure it from JavaConfig.
UPDATE
What about exceptions and error channel?
Since you get deal already with the throwExceptionOnLateReply I guess you send a message to the requestChannel via #MessagingGateway. The last one has errorChannel option. From other side the PublishSubscribeChannel has errorHandler option, for which you can use MessagePublishingErrorHandler with your errorChannel as a default one.
BTW, don't forget that Framework provides errorChannel bean and the endpoint on it for the LoggingHandler. So, think, please, if you really need to override that stuff. The default errorChannel is PublishSubscribeChannel, hence you can simply add your own subscribers to it.