[jira] [Work logged] (ARTEMIS-3198) Add ability to increase concurrency on core bridges

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-3198?focusedWorklogId=569892&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-569892 ]

ASF GitHub Bot logged work on ARTEMIS-3198:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 22/Mar/21 17:37
            Start Date: 22/Mar/21 17:37
    Worklog Time Spent: 10m 
      Work Description: AntonRoskvist opened a new pull request #3509:
URL: https://github.com/apache/activemq-artemis/pull/3509


   This commit adds a concurrency-option for the core bridges to handle high latency networks better


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 569892)
    Remaining Estimate: 0h
            Time Spent: 10m

> Add ability to increase concurrency on core bridges
> ---------------------------------------------------
>
>                 Key: ARTEMIS-3198
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3198
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>          Components: Broker
>            Reporter: Anton Roskvist
>            Priority: Minor
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add ability to increase concurrency on core bridges. This is useful for deploying bridges over high latency networks when the message volume is high. More concurrency allows for increased throughput.
>  
> I have run some tests locally, sending 20k messages across a WAN link. Using the default setting I was able to move all messages from point A to point B in: 2m5s31ms
> Adding another bridge, with identical parameters besides the name, the same 20k messages where moved in: 1min6s14ms
> Adding a third means: 33s.19ms
> So this is pretty much linear increase in throughput based on the number of bridges configured for the same destination. This works, but if multiple queues and destinations are involved the config file gets quite messy. Therefor I propose the addition of a concurrency property for these bridges, which basically spawns N amount of bridges behind the scenes instead, keeping the config file nice and tidy and the messages flying.
> Test summary:
> 20k messages (identical across runs), point A to point B over WAN:
> 1 bridge : 2m 5s 31ms
> 2 bridges: 1m 6s 14ms
> 3 bridges:   33s 19ms
> Br,
> Anton



--
This message was sent by Atlassian Jira
(v8.3.4#803005)