Skip to content

DelayerEndpointSpec doesn't allow to specify custom taskScheduler #9825

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

Closed
pziobron opened this issue Feb 13, 2025 · 2 comments
Closed

DelayerEndpointSpec doesn't allow to specify custom taskScheduler #9825

pziobron opened this issue Feb 13, 2025 · 2 comments

Comments

@pziobron
Copy link
Contributor

pziobron commented Feb 13, 2025

In what version(s) of Spring Integration are you seeing this issue?
6.2.11

Describe the bug
The custom taskScheduler is not configured for delay handler when using DelayerEndpointSpec#taskScheduler() method.
The default taskScheduler is used instead (IntegrationObjectSupport#getTaskScheduler() - taskScheduler is null)

To Reproduce

Use this code snippet:
subscribe(flow -> flow.delay(d -> d.messageGroupId("testDelayer").taskScheduler(myCustomTaskScheduler))).nullChannel();

when the delayer is executed the taskScheduler field is null and the default task scheduler is retrieved (IntegrationObjectSupport#getTaskScheduler())

I need to use this workaround to make it working properly:

DelayHandler handler = newDelayHandler("testDelayer", myCustomTaskScheduler);
subscribe(flow -> flow.handle(handler)).nullChannel();

Expected behavior

It should be possible to configure custom task scheduler using DelayerEndpointSpec#taskScheduler()

@pziobron pziobron added status: waiting-for-triage The issue need to be evaluated and its future decided type: bug labels Feb 13, 2025
@artembilan
Copy link
Member

Confirmed.
The ConsumerEndpointSpec does set the provided scheduler, but only into an endpoint for this handler.
I guess we just need to override that method on the DelayerEndpointSpec and set scheduler respectively to the handler as well.

I hope the config you provide is just for issue comment purpose.
Otherwise it does not make sense to delay a message just to discard it afterward...

@artembilan artembilan added this to the 6.5.0-M2 milestone Feb 13, 2025
@artembilan artembilan added in: core for: backport-to-6.3.x for: backport-to-6.4.x and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels Feb 13, 2025
spring-builds pushed a commit that referenced this issue Feb 13, 2025
Fixes: #9825
Issue link: #9825

The `DelayerEndpointSpec` extends `ConsumerEndpointSpec` which has a `taskScheduler()` option.
However this is set only to the endpoint for this `MessageHandler`.

* Override `taskScheduler()` method on the `DelayerEndpointSpec` to set
the provided `TaskScheduler` to the `DelayHandler` as well

(cherry picked from commit 12fee0a)
spring-builds pushed a commit that referenced this issue Feb 13, 2025
Fixes: #9825
Issue link: #9825

The `DelayerEndpointSpec` extends `ConsumerEndpointSpec` which has a `taskScheduler()` option.
However this is set only to the endpoint for this `MessageHandler`.

* Override `taskScheduler()` method on the `DelayerEndpointSpec` to set
the provided `TaskScheduler` to the `DelayHandler` as well

(cherry picked from commit 12fee0a)
@pziobron
Copy link
Contributor Author

pziobron commented Feb 13, 2025

Yes, agree, the code snippet doesn't make sense here, in the real code the other handler is processing the message after a delay.
I’ve simplified it too much :)

Should be:

subscribe(flow -> flow.delay(d -> d.messageGroupId("testDelayer").taskScheduler(myCustomTaskScheduler)).handle(otherHandler).nullChannel());

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants