Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

GH-5123: Add LockRegistry to AbstractMessageGroupStore

Browse Source 
Fixes: https://github.com/spring-projects/spring-integration/issues/5123

When `RedisMessageStore`, for example, adds and removes messages, it operates on two keys separately, which may cause problems in multi-threading due to non-atomic operations.
Although using Redis to delay messages is not a good idea, the abnormal loss of messages in the logs alerted me when the number of requests was not large.
By comparing the logs, the problem that the message group representing the metadata is not consistent with the actual message.

A simple solution is to add lock like in the `SimpleMessageStore`, which is also the approach taken in this pull request.

* Add `LockRegistry` to `AbstractMessageGroupStore`
* Normalize access levels and method name about the lock of `MessageGroupStore`
* Add document about the lock of `AbstractMessageGroupStore`
This commit is contained in:
NaccOll
2024-11-23 13:58:23 -05:00
committed by Artem Bilan
parent 12a643d494
commit 9962ee49a2
14 changed files with 284 additions and 214 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/reference/antora/modules/ROOT/pages/message-store.adoc
View File

@@ -158,3 +158,13 @@ It also allows the end marker to arrive at the aggregator before all the other r
In addition, for configuration convenience, a `GroupConditionProvider` contract has been introduced.
The `AbstractCorrelatingMessageHandler` checks if the provided `ReleaseStrategy` implements this interface and extracts a `conditionSupplier` for group condition evaluation logic.
[[use-lock-registry]]
== Use `LockRegistry`
Starting with version 6.5, the `AbstractMessageGroupStore` abstraction operates a metadata of message group with a lock.
This lock acquires the groupId and generated by `LockRegister`.
Its purpose is to operate on the atomicity of messages and message groups.
In multiple threads, adding or removing messages or updating metadata at the same time, some implementations may have message group errors if the lock is missing.
By default, the `DefaultLockRegistry` is used, any `LockRegister` can be injected via `AbstractMessageGroupStore.setLockRegistry()`, usually an implementation for the same persistent store.
See more xref:distributed-locks.adoc[Distributed Locks] for more information.

8
src/reference/antora/modules/ROOT/pages/whats-new.adoc
View File

@@ -25,4 +25,10 @@ See xref:control-bus.adoc[Control Bus] for more information.
The `AbstractCorrelatingMessageHandler` does not throw an `IllegalArgumentException` for the collection of payloads as a result of the `MessageGroupProcessor`.
Instead, such a collection is wrapped into a single reply message.
See xref:aggregator.adoc[Aggregator] for more information.
See xref:aggregator.adoc[Aggregator] for more information.
[[x6.4-message-store-with-locks]]
== The `LockRegistry` in the `MessageStore`
The `AbstractMessageGroupStore` now can be configured with a `LockRegistry` to perform series of persistent operation atomically.
See xref:message-store.adoc#use-lock-registry[Use LockRegistry] for more information.