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.
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?
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.
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.