Hi Ted,
Thanks for your response, the problem has been solved. You were right
indeed about the need for setting up linkRoutes in _both_zones. I will
further clarify the initial problem and what we did wrong, so that others
reading this might benefit. The setup we have looks like:
- Azure
- Mesh (connected via route-container connector to AWS mesh)
- Edge
- AWS
- Mesh
- Edge --> Broker
So what we were trying to do is:
- produce messages to the AWS broker to an address
*called telemetry.example*
- consume from this address by consuming via the Azure Edge router that
would ultimately establish a link with the AWS Broker via linkRouting.
- The reason we want to use linkRouting is that we want to create a
durable consumer for multiple clients.
- In our case to consume we subscribe to topics like
*telemetry.example::sub1
*and *telemetry.example::sub2* and so on.
- In this way each consumer would get its own dedicated queue on the
AWS Edge broker
In order to achieve this we had set up linkroutes from the AWS Edge --> AWS
Broker like:
*linkRoute { prefix: telemetry direction: in connection:
edge-amq-broker}linkRoute { prefix: telemetry direction: out connection:
edge-amq-broker }*
However, with only this config it didn't work. The culprit was that we also
needed linkRoutes setup for the *telemetry *prefix between:
- AWS Mesh <---> AWS Edge
- Azure Mesh <---> AWS Edge
Thanks for your help again.
Kind regards,
André van der Heijden
Op di 9 mrt. 2021 om 21:15 schreef Ted Ross <[email protected]>:
> Hi Andre,
>
> I'm not very clear on exactly what you're trying to do, but a few thoughts
> and questions come to mind.
>
> Did you consider joining the two zones into a single network using an
> inter-router connection instead of a route-container connection? This
> would provide link-route access from both zones to your destinations.
>
> Assuming you have good reasons for using a route-container connection
> between the zones:
>
> Does your remote-amq-mesh connection successfully connect?
>
> If so, did you create a link-route configuration in _both_ zones?
>
> I don't believe that the router normally issues an "amqp:not-found" error.
> Is it possible that the "address:queue" node does not exist on your
> destination and that your destination (broker?) is issuing the error?
>
> -Ted
>
> On Tue, Mar 9, 2021 at 2:48 PM André van der Heijden <
> [email protected]> wrote:
>
> > Dear qpid developers,
> >
> > I am wondering if it's possible to use linkrouting when you connect a
> mesh
> > in ZoneA (for example in Azure) to a mesh in ZoneB (for example in AWS).
> We
> > have established such a network and connect the two meshes via a
> connector
> > that looks like this:
> >
> > connector {
> > name: remote-amq-mesh
> > host: zone-b.example.azure.address.io
> > port: 443
> > saslMechanisms: EXTERNAL PLAIN
> >
> > sslProfile: client_tls
> > saslUsername: remote_connection@amq-interconnect-mesh
> > saslPassword: *****
> >
> > role: route-container
> > verifyHostname: false
> > idleTimeoutSeconds: 0
> > messageLoggingComponents: all
> > }
> >
> > When trying to connect to an address:queue that is in the other Zone and
> is
> > exposed via linkrouting, we get the following error:
> >
> > java.util.concurrent.ExecutionException:
> > javax.jms.InvalidDestinationException: Node not found [condition =
> > amqp:not-found]
> > at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> > at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> >
> > So at first sight, it seems that the above solution isn't working and we
> > cannot use linkrouting in a inter-cloud setup with the meshes connected
> > over a TLS route. Do you think this is plausible or do you have other
> > experiences?
> >
> > If the above is indeed impossible, would creating some routes that expose
> > AMQPS directly between different cloud environments, so that we can
> connect
> > the meshes inter-cloud via AMQPS directly be a good idea? Are there any
> > obvious downsides to this approach?
> >
> > Thanks a lot for your time.
> >
> > Kind regards,
> >
> > André van der Heijden
> >
>
