I've found that "The default "errorChannel" is a PublishSubscribeChannel" but I can't understand why. Can we use a direct channel instead? What is the downside of using a direct channel as an inbound channel for errorChannel?
[https://docs.spring.io/spring-integration/docs/5.0.5.RELEASE/reference/html/configuration.html#namespace-errorhandler][1]
You can override the default error channel with whatever channel type you prefer. There is no downside.
Pub/Sub with a logging handler subscribed is simply the default.
Related
I have a spring boot microservice with no controller endpoints. It operates entirely on a workflow using inbound-channel-adapter to query databases and perform some Service action when necessary.
I'd like to intercept all exceptions and judiciously send an alert to the appropriate parties when appropriate.
`#ControllerAdvice doesn't cut it, because there are no controllers.
Any recommendations on how to trap exceptions via an ExceptionHandler or Filter or other means?
Our app uses a org.springframework.integration.handler.LoggingHandler to log exceptions, extending that could be an option. I'd prefer not to have all my services extend a single base class that defines an #ExceptionHandler.
What is the "spring way" to trap exceptions from workflow channels and send notifications (email/slack/otherwise) to the appropriate user?
As Martin points in his comment, an errorChannel approach is used Spring Integration to handle exceptions in the flow. See error-channel option on that inbound-channel-adapter. It is errorChannel by default and it has indeed a LoggingHandler as a subscriber. You can stay with that global errorChannel as is and just have your own service-activator as a subscriber. Or you can configure your own, flow-specific error channel and its subscriber.
See more in documentation:
https://docs.spring.io/spring-integration/docs/current/reference/html/error-handling.html#error-handling
My spring boot application's is functionality it to listen to the messages on rabbitmq queue, do some processing in onMessage, and then publish the message on another rabbitmq queue. We are using spring-rabbit (1.7.2.RELEASE). We have configured listener using SimpleMessageListenerContainer.
My question is can i publish using he same channel on which I am reading he messages. Does spring-rabbit provides access to channel used by listener? so that same channel can be reused to publish?
Thanks,
Smita
If you use transactions (listener container), any operations performed by a transactional RabbitTemplate on the container thread will participate in the transaction and use the same channel.
If you are not using transactions, you can use a ChannelAwareMessageListener to access the channel the message was received on. See Message Listeners.
If you are using #RabbitListener you can add the Channel as a method parameter.
The current 1.7.x release is 1.7.9.
I have a simple JMS topic listener that i would like to hook with a spring-integration chain.
Basically, when a JMS message is received in the listener it has to be pushed into the chain's channel. Eventually the message is processed and pushed to an outbound-channel-adapter to be consumed.
The Spring Integration documentation mentions the use of asynchronous gateways but that uses Futures.
Isn't there a simple way to just put the message on a channel?
If there is an example that you can point to it would be great.
Thanks
Regards
Martin
If you want to run the flow on the listener thread, simply use a regular gateway (not an async one); this will allow the message to roll-back if the flow fails for any reason.
If you want to "fire and forget" you can make the request channel from the gateway an ExecutorChannel - see here.
I am new to spring integration and was going through the definition of service activator. The definition says that it is used to call a method and wrap the result in the response message. The definition also tells that it is a outbound gateway for invoking the bean method. I am not clear on the second statement. As I understand outbound gateway is to send the request from the application to external application and get the response back into the application. So, if a bean is invoked, it is invoked within the application and hence it should be inbound gateway right. Please let me know where I am wrong.
There are two types of integration - with external systems using various protocols, and with legacy java code using method invocation.
Within that, there are one-way integrations (provided by channel adapters) and two-way integration (request/response, provided by gateways). In each case, the integration can be inbound to the message flow, or outbound from it.
The <int: .../> namespace provides inbound and outbound channel adapters for invoking legacy code from the messaging flow, in the latter case (outbound) the method return type must be null. You could also invoke the same method with a service activator, but the channel adapter is preferred because it's clear it's a one-way integration.
On the inbound side, the messaging gateway (<int:gateway/>) is provided to allow legacy java code interact with the messaging flow ("call" it) without any specific dependencies.
There is no <int:outbound-gateway/> for invoking a method because the service activator provides that functionality.
If you can point us to the documentation that caused the confusion, we can try to improve it; please open a documentation JIRA issue.
I am currently working on an application with Spring Integration. The application requires guaranteed delivery and the option that the it will be functional for a specific amount of time that the external systems are unavailable without losing messages. Channels will be JMS backed with expiration time. I would like to understand which is the best practice for redelivery with Spring Integration. We are having the following options:
The application's integration flow has a number of outbound message gateways that requires RPC calls with external system. Statefull retry advice can be used. After the max attemps is reached for specific runtime exceptions the message will be addressed to a recovery channel. The recovery channel will use a delayer and will then address the message back to the original channel. After X times that the message will reach the recovery channel it will be addressed to the error channel where it will be simply logged without further processing. The delayer component in this case should use the jdbc message store option.
Another option would be to use the standard JMS option for redelivery. In this case the redelivery policy will not be implemented on Spring Integration but on the JMS provider side.
Which is the best practice for message redelivery with Spring Integration?
I'd say like this: don't reinvent the wheel!
If there is already some similar solution on the matter, just use it as is with its specific configuration.
Right, if JMS has that solution, just go ahead.
There is need, of course, to get deal with DLQ in case of message expiration or redelivery exhausting. But the concept is here.