[
https://issues.apache.org/jira/browse/ARTEMIS-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16251997#comment-16251997
]
Justin Bertram commented on ARTEMIS-1513:
-----------------------------------------
I believe I have a fix, and I've pushed that fix to [a branch on my GitHub
repo|https://github.com/jbertram/activemq-artemis/tree/ARTEMIS-1513]. However,
before I send a PR I need to consult with another developer in the community
who has more experience with the AMQP code than me. Feel free to take the fix
and try it out in your environment.
As far as I can tell the problem is that when the AMQP message is sent across
the bridge it is "embedded" into a core message because the bridge only
understands the core protocol. Once the core message arrives on the other side
the AMQP message is extracted, but the extracted message still has its
"address" property set to the original address where it was sent rather than
the forwarding-address defined on the bridge to the broker routes it to the
original address instead of where it really should go.
> Core Bridge configuration ignoring forwarding-address
> -----------------------------------------------------
>
> Key: ARTEMIS-1513
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1513
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.3.0
> Reporter: vina chen
> Priority: Blocker
>
> I configured a bridge using two servers
> *server 1 *
> <bridges>
> <bridge name="my-bridge">
> * <queue-name>SenderQueue</queue-name>
> <forwarding-address>ReceiverQueue</forwarding-address>*
> <retry-interval>1000</retry-interval>
> <retry-interval-multiplier>1.0</retry-interval-multiplier>
> <initial-connect-attempts>-1</initial-connect-attempts>
> <reconnect-attempts>-1</reconnect-attempts>
> <failover-on-server-shutdown>false</failover-on-server-shutdown>
> <use-duplicate-detection>true</use-duplicate-detection>
> <confirmation-window-size>10000000</confirmation-window-size>
> <user>amq</user>
> <password>amq</password>
> <static-connectors>
> <connector-ref>remote-connector</connector-ref>
> </static-connectors>
> </bridge>
> </bridges>
> *Server 2 *
> <bridges>
> <bridge name="my-bridge">
> * <queue-name>SenderQueue</queue-name>
> <forwarding-address>ReceiverQueue</forwarding-address>*
> <retry-interval>1000</retry-interval>
> <retry-interval-multiplier>1.0</retry-interval-multiplier>
> <initial-connect-attempts>-1</initial-connect-attempts>
> <reconnect-attempts>-1</reconnect-attempts>
> <failover-on-server-shutdown>false</failover-on-server-shutdown>
> <use-duplicate-detection>true</use-duplicate-detection>
> <confirmation-window-size>10000000</confirmation-window-size>
> <user>amq</user>
> <password>amq</password>
> <static-connectors>
> <connector-ref>remote-connector</connector-ref>
> </static-connectors>
> </bridge>
> </bridges>
> The bridges on both brokers have the same name. The intent is, when a
> message is sent to the SenderQueue on server1, it should be forwarded to the
> ReceiverQueue on server 2. And when a message is sent to the SenderQueue on
> server 2, it should be forwarded to the ReceiverQueue on server 1.
> However, I noticed that when a message is sent to the SenderQueue on server
> 1, it always ends up on SenderQueue on server 2. Since there are two
> bridges, the messages keep flying in both directions.
> So i copied the example provided by you guys at
> "apache-artemis-2.3.0/examples/features/standard/bridge/src/main/resources/activemq/"
> which has a bridge setup in one direction from queue sausage-factory on
> server0 to the queue mincing-machine on server1. I set this up on two
> different servers and when i sent a message to the sausage-factory queue on
> server0, the message never came to server1.
> Next i went ahead and created a sausage-factory queue on server1 and sent a
> message to the sausage-factory queue on server0 and the message shows up in
> the sausage-factory queue on server1. This tells me that the
> forwarding-address is being ignored by the code. I clearly noticed in the
> source code that if the forwarding address is null, then forward the message
> to the queue with the same name.
> Maybe the forwarding-address attribute in the broker.xml is not being
> de-serialized into the appropriate DTO objects. Pleaseeeeeee fix this issue.
> Thanks
> Vina
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
