[
https://issues.apache.org/jira/browse/ARTEMIS-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532227#comment-17532227
]
Anton Roskvist commented on ARTEMIS-3805:
-----------------------------------------
Hello [~clebertsuconic]
This seems to introduce an issue for me in a testing environment... messages
get "stuck" on $.artemis.internal...-queues. Setting the previous default
(producer-window-size=-1) resolves the issue and message flow resumes.
It might be because some messages getting forwarded in my case exceeds the 1MiB
window size and I guess smaller messages sent after those gets stuck "behind"
the large ones.
Again, setting the previous default solves it for me but if this is expected
behavior I guess it should be mentioned in the patch notes once 2.22.0 releases?
> Change default Bridge Producer Window Size to 1MB
> -------------------------------------------------
>
> Key: ARTEMIS-3805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3805
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.22.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The default producer value for a Bridge (clustered or not) is -1, meaning
> unlimited.
> We had seen scenarios where the target and source runs out of memory when
> running on slow networking or disk.
> I have looked into changing the implementation to back pressure the
> networking, however values are added into an Executor (through an Actor), and
> we the alternate back pressure would mean to add a new value to this
> executor, binding it towards the network.
> Which is a whole circle round back to the same problem... managing credits.
> instead of adding a new value, I will change the default value for Bridges
> which would have the same impact.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
