[
https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072899#comment-13072899
]
William Henry commented on QPID-3375:
-------------------------------------
Andrew,
Your points are good ones.
What I was seeing was the 'localhost' name of the source showing up in the
route list on the remote destination machine. This clearly is no good.
Perhaps checking if the the source and dest are localhost then it's ok and
allowing the use of localhost. That would solve all the 'make check' issues.
I was also seeing gaierror if the host is not in the DNS. We were not handling
that exception gracefully. But you are also correct in that the remote machine
may be able to resolve better than the machine where the route is being
generated. However that also seems a little bit messy from an admin perspective.
This is good feedback. And I think what I've sent in would need to be tidied up
some more in light of this. But I do think allowing erroneous routes to be
created is not desirable and seeing gaierror is also not desirable. (The
gaierro was happening on local broker too.)
> 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
