Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue May 25, 2017 · 8 comments
Assignees
Labels
in: messaging type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented May 25, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

Gary Russell commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

Rossen Stoyanchev commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 26, 2017

Gary Russell commented

Makes sense; thanks.

@spring-projects-issues spring-projects-issues added in: messaging type: enhancement labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0 RC2 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants