GenericMessagingTemplate - add overloaded doReceive() for dynamic receiveTimeout [SPR-15591]

[spring-projects-issues]

Gary Russell opened SPR-15591 and commented

Currently, doReceive() uses the provisioned receiveTimeout field - we have a requirement to provide a runtime timeout in some sendAndReceive use cases.

I would like to get this into 5.0 (RC2 or 3) if possible (I will submit a PR if there is agreement).

There are currently many convertSendAndReceive overloaded public methods. I am not sure it's necessary to double all of those to include the new parameter; I think it would be sufficient for subclasses to provide any specialized methods as needed (that would solve our use case, since we need to calculate the timeout using a SpEL expression anyway and it's likely we will need a custom evaluation context for each request anyway).

However, I can add a full set of overloads if you would prefer that.

Juergen Hoeller rstoyanchev please let me know your thoughts; thanks..

---

Affects: 5.0 RC1

Issue Links:

• INT-4033 Consider Adding Expressions for Gateway Properties ("is depended on by")

Referenced from: pull request #1435, and commits e06c4d5

[spring-projects-issues]

Juergen Hoeller commented

Sure, let's add those for RC2 as specialized methods. No full set of overloads necessary from my perspective.

[spring-projects-issues]

Rossen Stoyanchev commented

There is also a sendTimeout as well, right? Are you proposing support for both send and receive, per-message timeout values?

I agree that specialized methods would have to be the most practical solution. I'm only wondering could these be represented as message headers instead with GenericMessagingTemplate picking up message header overrides if present or otherwise falling back on the configured defaults?

[spring-projects-issues]

Gary Russell commented

Good catch on the send timeout - while not as common, we should support it too.

I like the idea of headers instead of changing the method signature, but I am concerned about them being propagated downstream and reused unexpectedly, so I think we'd have to make them readonly (or perhaps a new transient category) to avoid the propagation.

I'll play around with it and see what I come up with.

[spring-projects-issues]

Gary Russell commented

We will still need an overloaded receive() though, because there's no message in that case.

[spring-projects-issues]

Rossen Stoyanchev commented

Do you need receive() at this time or is that potentially?

[spring-projects-issues]

Gary Russell commented

Definitely needed - I mentioned it in the title but only talked about sendAndReceive in the description.

Here's my initial commit so you can take a look at what I have so far.

garyrussell@094616f

It turns out we can remove the headers in the template, since the message is still mutable until it's sent.

[spring-projects-issues]

Rossen Stoyanchev commented

Since those headers are primarily supported in GenericMessagingTemplate I'm wondering if they should also be defined there? GenericMessagingTemplate already exposes properties for timeout values and it could also define properties for header name overrides (with defaults based on constants). Alternatively MessageHeaders could document when these constants apply but it requires some explanation.

[spring-projects-issues]

Gary Russell commented

Makes sense; thanks.