Skip to content

Delayer with JdbcMessageStore does not release messages #8773

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
sbaby83 opened this issue Oct 24, 2023 · 1 comment
Closed

Delayer with JdbcMessageStore does not release messages #8773

sbaby83 opened this issue Oct 24, 2023 · 1 comment

Comments

@sbaby83
Copy link

sbaby83 commented Oct 24, 2023

Since 6.1.3 and the commit 032df62

The message is not released by delayer and this text appears in logs :

"No message in the Message Store to release: " + message +
". Likely another instance has already released it."

To Reproduce

IntegrationFlow
.from("firstTryChannel")
.delay(
"firstTry",
d -> d.defaultDelay(firstTryDelay)
.transactionalRelease(transactionInterceptorAdvice)
.maxAttempts(1)
.messageStore(jdbcMessageStore)
.delayedMessageErrorChannel("secondTryChannel")
)
.channel(FLOW_INPUT_CHANNEL)
.get();

Expected behavior

The message is released by delayer.

@sbaby83 sbaby83 added status: waiting-for-triage The issue need to be evaluated and its future decided type: bug labels Oct 24, 2023
@artembilan
Copy link
Member

Confirmed.
We have a logic in the DelayHandler like return ((MessageStore) this.messageStore).removeMessage(message.getHeaders().getId()) != null; where it fails now because we check if message is not in any group any more.

Unfortunately our DelayerHandlerRescheduleIntegrationTests is marked as @LongRunningTest and it is missed from any test suites 😢

@artembilan artembilan added in: core backport 5.5.x (EOL) for: backport-to-6.1.x and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels Oct 24, 2023
@artembilan artembilan added this to the 6.2.0 milestone Oct 24, 2023
@artembilan artembilan self-assigned this Oct 24, 2023
artembilan added a commit to artembilan/spring-integration that referenced this issue Oct 25, 2023
Fixes spring-projects#8773

The spring-projects#8732 introduced a filtering for messages in group.
So, plain `removeMessage()` doesn't work any more if message is connected to some group yet.
Therefore, `DelayHandler` is failing.

* Introduce `getMessageFromGroup()` and `removeMessageFromGroupById()` into `MessageGroupStore` API
and implement it respectively in all the stores
* Remove `@LongRunningTest` from delayer integration tests and adjust its config to delay not for a long

**Cherry-pick to `6.1.x`**
@tzolov tzolov closed this as completed in 5370d50 Nov 3, 2023
artembilan added a commit that referenced this issue Nov 3, 2023
Fixes #8773

The #8732 introduced a filtering for messages in group.
So, plain `removeMessage()` doesn't work any more if message is connected to some group yet.
Therefore, `DelayHandler` is failing.

* Introduce `getMessageFromGroup()` and `removeMessageFromGroupById()` into `MessageGroupStore` API
and implement it respectively in all the stores
* Remove `@LongRunningTest` from delayer integration tests and adjust its config to delay not for a long

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

# Conflicts:
#	spring-integration-core/src/main/java/org/springframework/integration/handler/DelayHandler.java
artembilan added a commit that referenced this issue Nov 3, 2023
The `this.messagePrefix + groupId + '_' + messageId` logic
is introduced since `6.2` via: 64f8ed5

The current fix for new `getMessageFromGroup()` and `removeMessageFromGroupById()`
is to retrieve group and then perform plain `get` and `delete` against just message id

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

Successfully merging a pull request may close this issue.

2 participants