Skip to content

Consider a Mechanism to Avoid Message Rebuilding on Every Track [INT-3983] #7925

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.

Sign up for GitHub

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

Jump to bottom
Closed
spring-operator opened this issue Apr 8, 2016 · 0 comments · Fixed by #8980
Closed

Consider a Mechanism to Avoid Message Rebuilding on Every Track [INT-3983] #7925

spring-operator opened this issue Apr 8, 2016 · 0 comments · Fixed by #8980
Labels
in: core type: enhancement
Milestone
6.3.0-M2

Comments

@spring-operator
Copy link
Contributor

Gary Russell opened INT-3983 and commented

See the discussion on #1764

No further details from INT-3983
@artembilan artembilan modified the milestones: General Backlog, Backlog Feb 14, 2023
@artembilan artembilan modified the milestones: Backlog, 6.3.0-M2 Mar 1, 2024
artembilan added a commit to artembilan/spring-integration that referenced this issue Mar 4, 2024
@artembilan
spring-projectsGH-7925: Make message history header as mutable
1dd0d17 
Fixes: spring-projects#7925

The `MessageHistory.write()` creates not only a new instance of the `MessageHistory`,
but also a new copy of the whole message.
This significantly impacts the performance when we have too many components to track

* Make `MessageHistory` as append-only container and create a new instance (plus message)
only on the first track when no prior history is present
* Change `WireTap`, `BroadcastingDispatcher`, `AbstractMessageRouter` and `AbstractMessageSplitter`
to use a new `AbstractIntegrationMessageBuilder.cloneMessageHistoryIfAny()` API for every branch a message
is produced.
Essentially, create a new message with copy of the message history to let that downstream sub-flow
have its own trace
* Modify failed unit tests for a new logic where message history header is not immutable anymore
* This also fixes an `AbstractMessageSplitter` for propagating its track into messages it emits
@artembilan artembilan mentioned this issue Mar 4, 2024
Merged
artembilan added a commit that referenced this issue Mar 5, 2024
@artembilan
GH-7925: Make message history header as mutable
2731e94 
Fixes: #7925

The `MessageHistory.write()` creates not only a new instance of the `MessageHistory`,
but also a new copy of the whole message.
This significantly impacts the performance when we have too many components to track

* Make `MessageHistory` as append-only container and create a new instance (plus message)
only on the first track when no prior history is present
* Change `WireTap`, `BroadcastingDispatcher`, `AbstractMessageRouter` and `AbstractMessageSplitter`
to use a new `AbstractIntegrationMessageBuilder.cloneMessageHistoryIfAny()` API for every branch a message
is produced.
Essentially, create a new message with copy of the message history to let that downstream sub-flow
have its own trace
* Modify failed unit tests for a new logic where message history header is not immutable anymore
* This also fixes an `AbstractMessageSplitter` for propagating its track into messages it emits

* * Do not clone message history header if only one consume in multi-publish
* Fix typos in docs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
in: core type: enhancement
Projects
None yet
Milestone
6.3.0-M2
Development

Successfully merging a pull request may close this issue.

GH-7925: Make message history header as mutable artembilan/spring-integration
2 participants
@artembilan @spring-operator