ForceReleaseProcessor will never be run when group condition is used and MongoDbMessageStore

[antonvovk]

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

6.1.0

To Reproduce
Use MongoDbMessageStore or ConfigurableMongoDbMessageStore as the MessageGroupStore implementation.
Create aggregator:

• Provide the groupConditionSupplier for the AbstractCorrelatingMessageHandler.
• Provide the groupTimeoutExpression for the AbstractCorrelatingMessageHandler with a positive value of 5-10 seconds.

Describe the bug

Let's take a look at this function from AbstractCorrelatingMessageHandler:

	private void processForceRelease(Object groupId, long timestamp, long lastModified) {
		MessageGroup messageGroup = this.messageStore.getMessageGroup(groupId);
		if (messageGroup.getTimestamp() == timestamp && messageGroup.getLastModified() == lastModified) {
			this.forceReleaseProcessor.processMessageGroup(messageGroup);
		}
	}

To run the forceReleaseProcessor the timestamp and lastModified must be the same as the corresponding properties from the message group that was fetched at the beginning of this function.
The timestamp and lastModified parameters come from the message group that was fetched in the processMessageForGroup function.

The problem is that after fetching the message group in the processMessageForGroup we do a call to setGroupConditionIfAny(message, messageGroup). And if we are using the group condition, this function will call messageStore.setGroupCondition() which will update the message group condition and its lastModifiedTime property in MongoDB implementation.

public void setGroupCondition(Object groupId, String condition) {
	updateGroup(groupId, lastModifiedUpdate().set("condition", condition));
}

So we end up in a situation where the lastModifiedTime is newer in the database but the message group fetched in the processMessageForGroup has an old value. This means that the condition in the forceReleaseProcessor will never be true if we are using the group condition.

Expected behavior

The message group instance in the processMessageForGroup should be updated after a call to setGroupConditionIfAny.

[martaisty]

+1 on this. Precisely described, @antonvovk

[artembilan]

Thank you for the report!

Indeed this is a problem we had caused via inconsistency with entity in the memory and whatever we have just update in the DB.

I see one way to fix quickly: do not update a lastModifiedTime field when we set a condition property. Technically we do not add any new messages to the group to really justify its modification.
So, probably we can treat updating options on a group metadata as non-modification to the whole group.

Another quick way is to re-fetch group in that setGroupConditionIfAny() and return its fresh instance.
This may cause a performance degradation since we are going to use one more DB call.

And final (probably the best) fix is to implement a new updateGroupCondition() API which would return for us just update in DB entity with fresh options respectively.

Since that API was introduced in an old still in support version:

	 * @since 5.5
	 */
	void setGroupCondition(Object groupId, String condition);

we have to fix this down to there as well, but we have to be careful do not make a breaking change.

I believe any solution we chose would be possible to back-port, but we have to decide together which one is good for all of us.

Please, help me with a choice 😄

[antonvovk]

Thanks for your quick response 😄

It would be good to have a quick fix that can be easily backported in 5.5.x/6.0.x/6.1.x. I think the second option will be the easiest and safest to do. The performance impact shouldn't be that noticeable and it will only affect those who use group condition.

Then in 6.2.0, the third option can be used which is really the best one to make a proper fix.

[artembilan]

OK! Let it be!

Then I'll implement quickly the second option.

[artembilan]

This the fix in related PR: #8686