[
https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072955#comment-13072955
]
Andrew Stitcher commented on QPID-3375:
---------------------------------------
Re the gai_error(): as messy as this behaviour seems I think is probably
correct (assuming I understand correctly). DNS lookups can be ephemeral and so
getting a lookup error now doesn't mean that if I try it in 5 minutes I will
still get an error. I'm pretty sure the builtin retry mechanism in the broker
link code will indeed retry if it gets a DNS resolution error so that you see
the exception in the link status, but then it retries later.
Or is the gai_error() appearing somewhere else?
> qpid-route does not resolve hostname and this causes problems with localhost
> among others
> -----------------------------------------------------------------------------------------
>
> Key: QPID-3375
> URL: https://issues.apache.org/jira/browse/QPID-3375
> Project: Qpid
> Issue Type: Bug
> Components: python tools
> Affects Versions: 0.10
> Environment: All
> Reporter: William Henry
> Assignee: Gordon Sim
> Labels: qpid-route
> Attachments: qpid-route, qpid-route.diff
>
>
> All the examples for Federation and qpid-route use localhost. For a multihost
> environment this is not a good idea.
> 1. 'localhost':<port> can end up in the routing table of remote host
> erroneously.
> 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the
> route erroneously
> 3. Even non localhost names don't get resolved and checked.
> Here is the test I was performing.
> I was doing some playing/testing with federation and I used two machines: my
> laptop (sligo) and a remote machine (buzz). I ran three brokers: 2 on sligo
> on
> ports 5672 and 5682 and one on remote on port 5682.
> From sligo I set up some links between all the brokers.
> (The problem has already occurred on the links above. Listing the routes will
> show the problem. But we'll go on)
> From sligo I set up a topic exchange on each broker:
> $ qpid-config -a localhost:5672 add exchange topic T.Prod
> $ qpid-config -a localhost:5682 add exchange topic T.Prod
> $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod
> On sligo I set up dynamic routes from source localhost:5672 to localhost:5682
> and buzz.somedomain.com:5682.
> When I list the routes from sligo I see:
> $ qpid-route route list localhost:5682
> localhost:5682 localhost:5672 T.Prod <dynamic>
> $ qpid-route route list buzz.somedomain.com:5682
> buzz.somedomain.com:5682 localhost:5672 T.Prod <dynamic>
> When I run example program drain on localhost:5682 on sligo I get the
> messages sent using the spout example program to default broker on sligo (on
> 5672).
> When I run drain on buzz I don't see anything.
> I see references to "localhost:5672" in the trace output of buzz's broker.
> This is BAD!
> We need qpid-route to resolve hostname before passing the arg to the remote
> broker.
> (In the meantime we might want to warn users of using 'localhost' with
> qpid-route across different hosts.)
> I will attach a diff and a new version of qpid-route for review.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
