You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "William Henry (JIRA)" <ji...@apache.org> on 2011/07/29 03:22:09 UTC
[jira] [Created] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
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
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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Andrew Stitcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072924#comment-13072924 ]
Andrew Stitcher commented on QPID-3375:
---------------------------------------
I agree that only allowing localhost in the source when we have localhost in the destination is a reasonable strategic heuristic to help eliminate some user error.
But I think that we should just print a stern warning if localhost is used rather than cause an error as we stand to stop behaviour that the admin might be trying to set up intentionally (not that I can think of a reason for it presently).
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081700#comment-13081700 ]
William Henry commented on QPID-3375:
-------------------------------------
I agree it's probably a cleaner place to put it.
But why a warning? How likely would it be that I would:
qpid-route link add biglong.name.com:12345 localhost:5672
and mean that localhost is the same as biglong.name.com?
Isn't it more likely an error/exception?
Also are we ok with the current gai_error handling? How likely is it that the average qpid-route user would figure out which name/service is the problem efficiently.
> 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-3375.patch, qpid-route, qpid-route, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Henry updated QPID-3375:
--------------------------------
Attachment: qpid-route
Here is a modified version with the diffs.
> 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
> 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-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Henry updated QPID-3375:
--------------------------------
Attachment: qpid-route-diff.txt
svn diff output
> 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, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3375) qpid-route does not
resolve hostname and this causes problems with localhost among others
Posted by "Andrew Stitcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072924#comment-13072924 ]
Andrew Stitcher edited comment on QPID-3375 at 7/29/11 6:18 PM:
----------------------------------------------------------------
I agree that only allowing localhost in the source when we have localhost in the destination is a reasonable tactical heuristic to help eliminate some user error.
But I think that we should just print a stern warning if localhost is used rather than cause an error as we stand to stop behaviour that the admin might be trying to set up intentionally (not that I can think of a reason for it presently).
was (Author: astitcher):
I agree that only allowing localhost in the source when we have localhost in the destination is a reasonable strategic heuristic to help eliminate some user error.
But I think that we should just print a stern warning if localhost is used rather than cause an error as we stand to stop behaviour that the admin might be trying to set up intentionally (not that I can think of a reason for it presently).
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Gordon Sim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081717#comment-13081717 ]
Gordon Sim commented on QPID-3375:
----------------------------------
I'm neutral on the warning v. error question. The key as I see it is simply to avoid the issue going undetected. Andrew suggested a warning, I went with that in the example patch. No objection to it being an error either. I doubt anyone would ever want to do this to be honest.
The error handling could certainly also be improved, but strikes me as perhaps a separate issue.
> 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-3375.patch, qpid-route, qpid-route, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Assigned] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Gordon Sim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gordon Sim reassigned QPID-3375:
--------------------------------
Assignee: Gordon Sim
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072640#comment-13072640 ]
William Henry commented on QPID-3375:
-------------------------------------
The modification tries to resolve the hostnames provided and will throw and exception if either is not resolved.
IT then checks to see if the resolved name is local loopback and throws an exception if it is.
> 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
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Gordon Sim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072900#comment-13072900 ]
Gordon Sim commented on QPID-3375:
----------------------------------
Yes, its really the latter. In general we connect to the 'destination' broker and ask it to connect to the 'source' broker, passing the address exactly as given on the command line. If the destination broker is remote (i.e. on a different box), then localhost there is different from localhost where the command is being run, and we have ambiguity. The roles of the brokers are reversed if src-is-local is chosen. (The naming is terrible throughout here).
Perhaps the simplest fix is just to print an error and exit if the source is the loopback address and the destination is not(?) (vice versa for src-is-local mode). That way the tests will all still work (shorthand localhost is fine if everything is on one box) but the ambiguous case will be made more obvious to users.
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Andrew Stitcher (JIRA)" <ji...@apache.org>.
[ 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082455#comment-13082455 ]
William Henry commented on QPID-3375:
-------------------------------------
I think explicitly resolving is a good idea. Why not? It costs little and is more "correct".
And IMO I still think that using localhost in the use case we're discussing is an error and not a warning. I think in almost all cases the resulting task of such a warning will be a wasteful 'qpid-route link del'. Therefore make it an exception and not a warning. :-)
> 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-3375.patch, qpid-route, qpid-route, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Henry updated QPID-3375:
--------------------------------
Attachment: qpid-route
Added the new qpid-route
> 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, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Issue Comment Edited] (QPID-3375) qpid-route does not
resolve hostname and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081217#comment-13081217 ]
William Henry edited comment on QPID-3375 at 8/8/11 9:36 PM:
-------------------------------------------------------------
Added svn diff output
was (Author: whenry):
svn diff output
> 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, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
William Henry updated QPID-3375:
--------------------------------
Attachment: qpid-route.diff
This file shows the diff between the the current version of qpid-route and the new version that checks the hostname.
> 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
> 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-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Gordon Sim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gordon Sim updated QPID-3375:
-----------------------------
Attachment: QPID-3375.patch
Suggested alternative fix. I think this is a little simpler and more direct. There may be a more elegant test for loopback; what is there can also be expanded (e.g. when IPv6 addresses are supported or tested).
> 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-3375.patch, qpid-route, qpid-route, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Andrew Stitcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072890#comment-13072890 ]
Andrew Stitcher commented on QPID-3375:
---------------------------------------
Actually it's not clear to me what the bug here actually is:
Is it that one broker will pass one of its routes to another federated broker, if this is so then this behaviour can never be guaranteed to work as the view of the network may be different from the two locations irrespective of loopback addresses. But the best hope of making this work is to pass DNS names around and not IP addresses.
OR
Is it that the admin needs to take into account the difference between networking where he is and where the broker he configures is? In this case we need to improve the documentation and tools substantially, because qpid-route doesn't really make explicit from which viewpoint the network names are resolved. We just talk about source and destination without being clear from whose viewpoint the routes are named.
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Gordon Sim (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081914#comment-13081914 ]
Gordon Sim commented on QPID-3375:
----------------------------------
I think we are simply trying to reduce a common error. It seems a lot less likely that people enter localhost.localdomain as the hostname and its very unlikely that localhost is in fact something other than loopback.
> 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-3375.patch, qpid-route, qpid-route, qpid-route-diff.txt, 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Andrew Stitcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072885#comment-13072885 ]
Andrew Stitcher commented on QPID-3375:
---------------------------------------
I think there are a number of problems with this proposed change:
1. Federation tests during "make check" depend on using loopback addresses:
They set up multiple brokers on a single machine and wire them together with loopback routes. Disallowing loopback routes would prevent this testing. It may be possible to figure out an external network address for the machine, but this cannot be guaranteed (not all machines have an external address, but all have loopback with most current networking setups)
2. You can't resolve the names to get IP addresses at configuration time:
* The current federation mechanism automatically retries under many circumstances including name resolution failure, this is actually a real feature in that it allows the name->address mapping to change or to round robin in a way that resolving ahead of time doesn't.
* In a mixed IPv4/IPv6 network doing the lookup somewhere other than the machine actually making the connection _at the time the connection is needed_ may not get the correct answer. Actually the is is true for any network but in a mixed network the v4 and v6 connectivity may differ across the network.
* The address resolution will usually return multiple IP addresses which need to be tried in turn. You can't do this in config-route as it can currently only send a single name.
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078703#comment-13078703 ]
William Henry commented on QPID-3375:
-------------------------------------
Andrew, I'll take another look at this as soon as I can sit back down with the code.
I will:
1) Allow localhost then both dest and source are the localhost.
2) Check the gai_error to see if my handling of it is correct. Currently when I catch it I throw an exception.
Thanks
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "William Henry (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081215#comment-13081215 ]
William Henry commented on QPID-3375:
-------------------------------------
Made some changes. Let me know what you think.
Allow localhost when both machines are localhost (but diff brokers)
I warn of a gai_error if it can't resolve locally but don't throw an exception. The gai_error gets caught elsewhere. (I think it is only thrown if the remote machine can't resolve either)
> 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-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname
and this causes problems with localhost among others
Posted by "Andrew Stitcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081903#comment-13081903 ]
Andrew Stitcher commented on QPID-3375:
---------------------------------------
It's not really correct to check against the string form "localhost" as there is only convention that marks it out as a name for the loopback interface, and moreover there will be a number of names in most systems that give loopback (eg "localhost.localdomain" as well)
Probably the correct test IMO is to resolve the name and then check whether the resolved name is a loopback address (127.0.0.1/::1). However this is fallible as you are not testing for loopback on the actual machine that you will send the route to and so the name resolutions could be different.
This inability to do an exactly correct job is the major reason to only produce a warning IMO.
> 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-3375.patch, qpid-route, qpid-route, qpid-route-diff.txt, 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-subscribe@qpid.apache.org