-
Notifications
You must be signed in to change notification settings - Fork 181
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
W-11599413-asyncScope-duke #2365
base: v4.4
Are you sure you want to change the base?
Conversation
|=== | ||
|
||
== Async Scopes versus Subflows | ||
|
||
Unlike a subflow, an Async scope: | ||
Unlike the xref:flow-component.adoc[Subflow}, the Async scope: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlike the xref:flow-component.adoc[Subflow}, the Async scope: | |
// TODO: Provide some context for this section, why we want to distinguish | |
// the components. | |
Unlike the xref:flow-component.adoc[Subflow}, the Async scope: |
|
||
See xref:execution-engine.adoc#backpressure[Back-Pressure Management] for details about Mule behavior after reaching the maximum concurrency value. | ||
Upon reaching maximum concurrency,the scope cannot receive additional requests. See xref:execution-engine.adoc#backpressure[Back-Pressure Management] for details about the behavior of Mule when it reaches the maximum concurrency value. | ||
|=== | ||
|
||
== Async Scopes versus Subflows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Remove this section and just talk about async characteristics, not in relation to Subflows
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: @IvanAndresFritzler check if any scope inherits exception strategy from main scope
|
||
In other words, if the payload of your message is a mutable object (for example, a bean with different fields in it) and a message processor in your Async scope changes the value of one of the fields, the message processors outside of the Async scope see the changed values. | ||
// TODO: DOES THIS INFO BELONG IN THIS SECTION? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: create section title for how async handles mutable objects
|
||
In other words, if the payload of your message is a mutable object (for example, a bean with different fields in it) and a message processor in your Async scope changes the value of one of the fields, the message processors outside of the Async scope see the changed values. | ||
// TODO: DOES THIS INFO BELONG IN THIS SECTION? | ||
// TODO: Do we have a recommendation here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: @IvanAndresFritzler we can say something like copy the payload if going to mutate it, only applies if doing something after the async. would need to add custom code for this.
Writer's Quality Checklist
Before merging your PR, did you: