[
https://issues.apache.org/jira/browse/ARTEMIS-5437?focusedWorklogId=967319&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-967319
]
ASF GitHub Bot logged work on ARTEMIS-5437:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Apr/25 18:29
Start Date: 23/Apr/25 18:29
Worklog Time Spent: 10m
Work Description: clebertsuconic merged PR #5641:
URL: https://github.com/apache/activemq-artemis/pull/5641
Issue Time Tracking
-------------------
Worklog Id: (was: 967319)
Time Spent: 50m (was: 40m)
> Add a more advanced message bridging feature to AMQP broker connections
> -----------------------------------------------------------------------
>
> Key: ARTEMIS-5437
> URL: https://issues.apache.org/jira/browse/ARTEMIS-5437
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: AMQP
> Affects Versions: 2.40.0
> Reporter: Timothy A. Bish
> Assignee: Timothy A. Bish
> Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The AMQP broker connection currently offers a somewhat primitive bridge
> capability by offering configuration of SENDER and RECEIVER elements which
> can perform some basic bridging primarily between Artemis instances given the
> way the send to address, receiver from queue behavior is carried over into
> the implementation.
> This new AMQP bridge feature offers a more advanced and flexible bridge
> capability that allows for messages to be bridged from or to a remote with
> various configuration options to account for the remote not being an Artemis
> peer but leveraging some Artemis capabilities like Core message tunneling
> over AMQP when the remote is an Artemis instance. By default the receivers
> for this bridge implementation activate only on local demand being present
> but can be configured to be always active as the older RECEIVER capability
> currently behaves.
> This implementation also incorporates features implemented in the AMQP
> federation bits that deal with draining link credit on receivers before
> detaching to avoid potential duplicates and idling links if demand tracking
> is active (default mode) to avoid rapid create and destroy cycles for bridge
> receiver links. There is also in-built link recovery mechanisms that will
> attempt to recreate links that are closed by the remote on a periodic basis.
> Also like federation Queue receivers the new bridge receivers can be
> configured in pull mode to only offer credit when the local Queue has no
> pending backlog to avoid moving messages until there is a need.
> A example of configuration for an AMQP broker connection bridge is shown below
> {code:xml}
> <amqp-connection uri="tcp://host:port"
> name="my-bridge-configuration">
> <bridge>
> <bridge-from-queue name="policy-name-1">
> <include address-match="#" queue-match="someQueue" />
> <property key="amqpCredits" value="0"/>
> <property key="amqpPullConsumerCredits" value="10"/>
> </bridge-from-queue>
> <bridge-to-queue name="policy-name-2">
> <include address-match="test" queue-match="myQueue" />
> </bridge-to-queue>
> <bridge-from-address name="policy-name-3">
> <include address-match="test-address" />
> <exclude address-match="all.#" />
> </bridge-from-address>
> <bridge-to-address name="policy-name-4">
> <include address-match="send-to-address" />
> <exclude address-match="all.#" />
> </bridge-to-address>
> </bridge>
> </amqp-connection>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
