On Outbound Gateways deprecate "request-timeout" and provide "reply-timeout" across Components [INT-2248]

[spring-operator]

Gunnar Hillert opened INT-2248 and commented

There are places where we are currently interpreting a request-timeout attribute as if it were a reply-timeout. For example, have a look at the HttpOutboundGatewayParser. We need to deprecate those attributes, replace them with reply-timeout and document clearly what that means.

This Jira serves as a parent umbrella issue. Sub-issues will be created for all affected Outbound Gateways.

E.g. see #6227

The parser code would basically look like this:

IntegrationNamespaceUtils.setValueIfAttributeDefined(builder, element, "reply-timeout", "sendTimeout"); 

We could add a warn-level message for use of the then deprecated request-timeout attribute.

The real request-timeout, is actually not applicable in the first place, since the receive-timeout can be specified on a Poller element (as it should be) whenever the request-channel referenced is in fact a PollableChannel.

Important

There are valid edge-cases. E.g. The Payload Enricher when using a request channel acts like a gateway. In that case a request-timeout is perfectly valid. In fact, the wrapped Gateway in that case behaves more like an Inbound Gateway. I wanted to mention this to illustrate a case where the delineation of Outbound Gateways is starting to blur.

Take a look at #6198 - When we update the documentation we need to make sure to mention this and explain the differences.

---

Affects: 2.1 M3

Sub-tasks:

• Jdbc Outbound Gateways - Change "request-timeout" to "reply-timeout" [INT-2245] #6227 Jdbc Outbound Gateways - Change "request-timeout" to "reply-timeout"

• HTTP outbound gateway - 'request-timeout' should be 'reply-timeout' [INT-2251] #6225 HTTP outbound gateway - 'request-timeout' should be 'reply-timeout'

Issue Links:

• Change from request-timeout to reply-timeout in HttpOutboundGateway is not reflected in the SI reference guide [INT-2450] #6429 Change from request-timeout to reply-timeout in HttpOutboundGateway is not reflected in the SI reference guide
  ("is depended on by")
• Add reply-timeout to All Outbound Gateways [INT-2262] #6247 Add reply-timeout to All Outbound Gateways
  ("is superseded by")
• Select and Implement New Atrtibute Reflecting Remote Server Response Timeout (for Outbound Gateways) [INT-2263] #6248 Select and Implement New Atrtibute Reflecting Remote Server Response Timeout (for Outbound Gateways)
  ("is superseded by")
• TCP Outbound Gateway - Reconcile reply-timeout with INT-2262 and INT-2263 [INT-2264] #6249 TCP Outbound Gateway - Reconcile reply-timeout with Add reply-timeout to All Outbound Gateways [INT-2262] #6247 and Select and Implement New Atrtibute Reflecting Remote Server Response Timeout (for Outbound Gateways) [INT-2263] #6248
  ("is superseded by")

[spring-operator]

Mark Fisher commented

Maybe we don't need to deprecate since technically using "request-timeout" in that way is a bug. We should instead add this to the migration guide. Another factor for this decision is that the timeout for sending a message to the reply-channel is only used when that channel has a blocking send, and it's probably a very rarely relied-upon feature.

[spring-operator]

Mark Fisher commented

Oleg, I addressed HTTP and Gunnar has JDBC. I don't know if there are others, but please check all of the outbound-gateways for this same issue.

[spring-operator]

Oleg Zhurakousky commented

Interesting that for JMS we have 'receive-timeout' instead of request-timeout

[spring-operator]

Mark Fisher commented

That 'receive-timeout' is set on the underling MessageListener container where it is used as the timeout for each JMS Message being received. So that is separate from the timeouts associated with the gateway's request-channel or reply-channel. It appears that the reply-timeout is used properly in the JMS gateway (passed to the underlying sendTimeout for the reply being sent with the messagingTemplate).

[spring-operator]

Mark Fisher commented

At this point, I think we might have caught all the cases where 'request-timeout' was accidentally being used for what should have been 'reply-timeout' (the actual use is sendTimeout for the sending of a reply to the reply-channel). We just need to do a quick scan to ensure we did not miss any.

[spring-operator]

Gary Russell commented

No additional gateways found that mis-use request-timeout in this way. See related issues.