Fix ThreadSPropagationChInterceptor for stacking #8735
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Related SO thread: https://stackoverflow.com/questions/77058188/multiple-threadstatepropagationchannelinterceptors-not-possible The current `ThreadStatePropagationChannelInterceptor` logic is to wrap one message to another (`MessageWithThreadState`), essentially stacking contexts. The `postReceive()` logic is to unwrap a `MessageWithThreadState`, therefore we deal with the latest pushed context which leads to the `ClassCastException` * Rework `ThreadStatePropagationChannelInterceptor` logic to reuse existing `MessageWithThreadState` and add the current context to its `stateQueue`. Therefore, the `postReceive()` will `poll()` the oldest context which is, essentially, the one populated by this interceptor before, according to the interceptors order * Fix `AbstractMessageChannel.setInterceptors()` to not modify provided list of interceptors * The new `ThreadStatePropagationChannelInterceptorTests` demonstrates the problem described in that mentioned SO question and verifies that context are propagated in the order they have been populated **Cherry-pick to `6.1.x` & `6.0.x`**
…e scenario. Essentially, copy the state queue to a new decorated message * Fix `BroadcastingDispatcher` to always decorate message, even if not `applySequence`
|
OK. Thinking about this one more time, I convince myself that this wrapping approach is not so good. Especially when we send the same message to several handlers like in case of publish-subscribe channel. We may still have this Probably that should be done as a new feature just for current version since it is a bit breaking change and this PR still makes sense as bug fix for previous version. |
garyrussell
approved these changes
Sep 18, 2023
garyrussell
pushed a commit
that referenced
this pull request
Sep 18, 2023
* Fix ThreadSPropagationChInterceptor for stacking Related SO thread: https://stackoverflow.com/questions/77058188/multiple-threadstatepropagationchannelinterceptors-not-possible The current `ThreadStatePropagationChannelInterceptor` logic is to wrap one message to another (`MessageWithThreadState`), essentially stacking contexts. The `postReceive()` logic is to unwrap a `MessageWithThreadState`, therefore we deal with the latest pushed context which leads to the `ClassCastException` * Rework `ThreadStatePropagationChannelInterceptor` logic to reuse existing `MessageWithThreadState` and add the current context to its `stateQueue`. Therefore, the `postReceive()` will `poll()` the oldest context which is, essentially, the one populated by this interceptor before, according to the interceptors order * Fix `AbstractMessageChannel.setInterceptors()` to not modify provided list of interceptors * The new `ThreadStatePropagationChannelInterceptorTests` demonstrates the problem described in that mentioned SO question and verifies that context are propagated in the order they have been populated **Cherry-pick to `6.1.x` & `6.0.x`** * * Fix `ThreadStatePropagationChannelInterceptor` for publish-subscribe scenario. Essentially, copy the state queue to a new decorated message * Fix `BroadcastingDispatcher` to always decorate message, even if not `applySequence` * * Fix unused import in the `BroadcastingDispatcher` * * Fix unused import in the `ThreadStatePropagationChannelInterceptor`
garyrussell
pushed a commit
that referenced
this pull request
Sep 18, 2023
* Fix ThreadSPropagationChInterceptor for stacking Related SO thread: https://stackoverflow.com/questions/77058188/multiple-threadstatepropagationchannelinterceptors-not-possible The current `ThreadStatePropagationChannelInterceptor` logic is to wrap one message to another (`MessageWithThreadState`), essentially stacking contexts. The `postReceive()` logic is to unwrap a `MessageWithThreadState`, therefore we deal with the latest pushed context which leads to the `ClassCastException` * Rework `ThreadStatePropagationChannelInterceptor` logic to reuse existing `MessageWithThreadState` and add the current context to its `stateQueue`. Therefore, the `postReceive()` will `poll()` the oldest context which is, essentially, the one populated by this interceptor before, according to the interceptors order * Fix `AbstractMessageChannel.setInterceptors()` to not modify provided list of interceptors * The new `ThreadStatePropagationChannelInterceptorTests` demonstrates the problem described in that mentioned SO question and verifies that context are propagated in the order they have been populated **Cherry-pick to `6.1.x` & `6.0.x`** * * Fix `ThreadStatePropagationChannelInterceptor` for publish-subscribe scenario. Essentially, copy the state queue to a new decorated message * Fix `BroadcastingDispatcher` to always decorate message, even if not `applySequence` * * Fix unused import in the `BroadcastingDispatcher` * * Fix unused import in the `ThreadStatePropagationChannelInterceptor`
|
...and cherry-picked. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related SO thread: https://stackoverflow.com/questions/77058188/multiple-threadstatepropagationchannelinterceptors-not-possible
The current
ThreadStatePropagationChannelInterceptorlogic is to wrap one message to another (MessageWithThreadState), essentially stacking contexts. ThepostReceive()logic is to unwrap aMessageWithThreadState, therefore we deal with the latest pushed context which leads to theClassCastExceptionThreadStatePropagationChannelInterceptorlogic to reuse existingMessageWithThreadStateand add the current context to itsstateQueue.Therefore, the
postReceive()willpoll()the oldest context which is, essentially, the one populated by this interceptor before, according to the interceptors orderAbstractMessageChannel.setInterceptors()to not modify provided list of interceptorsThreadStatePropagationChannelInterceptorTestsdemonstrates the problem described in that mentioned SO question and verifies that context are propagated in the order they have been populatedCherry-pick to
6.1.x&6.0.x