Skip to content

Conversation

@artembilan
Copy link
Member

When we use POJO methods in the IntegrationFlowAdapter, the IntegrationFlowAdapter is set as a target for the MessagingMethodInvokerHelper. When endpoint is started by the application context, such a start() is propagated down to the MessagingMethodInvokerHelper.
And in our case back into an IntegrationFlowAdapter instance. This one, in turn, starts its IntegrationFlow internally which leads to the start of the mentioned endpoint in the beginning.
Therefore, we cause a recursive start() call on this endpoint from itself. The running flag is set when we are already done with the doStart() logic. Therefore a recursive start() call leads to two concurrent polling tasks in the AbstractPollingEndpoint.

  • Check also for the active flag in the AbstractEndpoint.start() and reset it in case of exception in the doStart()

Cherry-pick to 5.5.x

When we use POJO methods in the `IntegrationFlowAdapter`,
the `IntegrationFlowAdapter` is set as a `target` for the `MessagingMethodInvokerHelper`.
When endpoint is started by the application context, such a `start()` is propagated
down to the `MessagingMethodInvokerHelper`.
And in our case back into an `IntegrationFlowAdapter` instance.
This one, in turn, starts its `IntegrationFlow` internally which leads to the
start of the mentioned endpoint in the beginning.
Therefore, we cause a recursive `start()` call on this endpoint from itself.
The `running` flag is set when we are already done with the `doStart()` logic.
Therefore a recursive `start()` call leads to two concurrent polling tasks
in the `AbstractPollingEndpoint`.

* Check also for the `active` flag in the `AbstractEndpoint.start()`
and reset it in case of exception in the `doStart()`

**Cherry-pick to `5.5.x`**
@artembilan
Copy link
Member Author

@garyrussell ,

this was the easiest way to fix the problem.
I'm not sure if there is an other option to check if we are causing a recursive start() call from itself.

Thank you!

@garyrussell garyrussell merged commit 532692b into spring-projects:main Oct 27, 2022
garyrussell pushed a commit that referenced this pull request Oct 27, 2022
* Fix double start for `AbstractEndpoint`

When we use POJO methods in the `IntegrationFlowAdapter`,
the `IntegrationFlowAdapter` is set as a `target` for the `MessagingMethodInvokerHelper`.
When endpoint is started by the application context, such a `start()` is propagated
down to the `MessagingMethodInvokerHelper`.
And in our case back into an `IntegrationFlowAdapter` instance.
This one, in turn, starts its `IntegrationFlow` internally which leads to the
start of the mentioned endpoint in the beginning.
Therefore, we cause a recursive `start()` call on this endpoint from itself.
The `running` flag is set when we are already done with the `doStart()` logic.
Therefore a recursive `start()` call leads to two concurrent polling tasks
in the `AbstractPollingEndpoint`.

* Check also for the `active` flag in the `AbstractEndpoint.start()`
and reset it in case of exception in the `doStart()`

**Cherry-pick to `5.5.x`**

* * Change assert for message timestamps to `isCloseTo()` with percentage

* * Change `catch` in the `AbstractEndpoint.start()` to `RuntimeException`:
the `doStart()` cannot throw unchecked exceptions by definition

* * Fix imports in `AbstractEndpoint`
@garyrussell
Copy link
Contributor

...and cherry-picked as 8f809a7

@artembilan artembilan modified the milestones: 6.0 GA, 6.0.0-RC2 Nov 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants