0

I'm currently working on a Spring Integration DSL project and I've a flow that requires handling errors differently depending on the part of the flow that fails.

My current approach was to create subFlows by chaining .gateway methods, but I'm having trouble handling exceptions as the .gateway hangs indefinetly waiting for a reply after sending the message to the defined .errorChannel, which isn't required for my case, even when I configure it as .requireReply(false).

Is there any other better approach to divide the flow and handle exceptions conditionally? Could .gateways be configured to cut the flow and call postSend so channels are available after sending a message to the .errorChannel?

gnzlrm
  • 190
  • 1
  • 12

1 Answers1

1

As long as only direct channels (default) are used, you can simply set the gateway reply timeout to 0, which will prevent the thread from hanging after an error has been "consumed".

Gary Russell
  • 166,535
  • 14
  • 146
  • 179
  • Thanks for your help, Gary. My main concern is that if my approach isn't appropiate: I'm using Gateways only because I found that they'd allow me to configure an specific errorChannel, and knew nothing about other implications about them (like requiring a reply). Is correct to use them for this purpose, or are other elements better designed to handle this situations? – gnzlrm Jun 07 '18 at 16:34
  • Yes, it is the correct technique if you want to use a different error channel in the downstream flow. If the error flow re-throws (or throws a new exception), there is no problem, but if it "consumes" (handles) the error and you simply want the flow to stop at that point, you need a 0 timeout; it's more tricky if the subflow has async operations. Another alternative is to add a request handler advice to individual components. See [Adding Behavior to Endpoints](https://docs.spring.io/spring-integration/reference/html/messaging-endpoints-chapter.html#message-handler-advice-chain). – Gary Russell Jun 07 '18 at 17:38