[
https://issues.apache.org/jira/browse/ARTEMIS-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy A. Bish updated ARTEMIS-5437:
-------------------------------------
Description:
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}
was:
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 behaved.
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 to avoid rapid create and destroy cycles for bridge 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 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}
> 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: 10m
> 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
