You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2014/12/02 13:52:13 UTC
[jira] [Comment Edited] (QPID-6161) [Java Broker] Add support for
virtual host aliasing
[ https://issues.apache.org/jira/browse/QPID-6161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231424#comment-14231424 ]
Keith Wall edited comment on QPID-6161 at 12/2/14 12:51 PM:
------------------------------------------------------------
A couple of comments:
h2. HostNameAliasImpl
# Thread should be daemon, just in case
# Suggest thread name incorporates the port number,
# I think a minority of users use a binding address. Why not reorganise the code so that _localAddressNames is computed once for the wildcard address once (at startup) and thereby avoid the unnecessary cost.
# The binding address should identity the IP address of a single network interface. We currently allow this to be specified by a symbolic name resolved within DNS. This means that there is a potential for InetAddress.getByName() to throw a UHE. If this were to happen, perhaps owing to a transient condition, matches() would utilise an empty set and would silently return the wrong result At very least we should be logging the UHE for problem resolution purposes. (I did wonder if AmqPortImpl should verify that a bindingAddress belongs to the set described by NetworkInterface.getNetworkInterfaces(), but on second thoughts, perhaps the ability to specify a binding address symbolically will be useful in a cloud space).
# I realise the SocketException would be unexpected, but we should log, just in case.
h2. PatternMatchingAliasImpl
# Suggest the code is changed to compile the pattern as a side effect of setting the pattern attribute. This has the advantage of fail early. It will also serve to avoid the repeated pattern compilation that would otherwise occur on each virtual host connection.
was (Author: k-wall):
A couple of comments:
h1. HostNameAliasImpl
# Thread should be daemon, just in case
# Suggest thread name incorporates the port number,
# I think a minority of users use a binding address. Why not reorganise the code so that _localAddressNames is computed once for the wildcard address once (at startup) and thereby avoid the unnecessary cost.
# The binding address should identity the IP address of a single network interface. We currently allow this to be specified by a symbolic name resolved within DNS. This means that there is a potential for InetAddress.getByName() to throw a UHE. If this were to happen, perhaps owing to a transient condition, matches() would utilise an empty set and would silently return the wrong result At very least we should be logging the UHE for problem resolution purposes. (I did wonder if AmqPortImpl should verify that a bindingAddress belongs to the set described by NetworkInterface.getNetworkInterfaces(), but on second thoughts, perhaps the ability to specify a binding address symbolically will be useful in a cloud space).
# I realise the SocketException would be unexpected, but we should log, just in case.
h1. PatternMatchingAliasImpl
# Suggest the code is changed to compile the pattern as a side effect of setting the pattern attribute. This has the advantage of fail early. It will also serve to avoid the repeated pattern compilation that would otherwise occur on each virtual host connection.
> [Java Broker] Add support for virtual host aliasing
> ---------------------------------------------------
>
> Key: QPID-6161
> URL: https://issues.apache.org/jira/browse/QPID-6161
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: 0.31
>
>
> Add the ability to configure how a connection request for a given "host"/"virtualhost" is translated to assigning to a virtual host inside the broker. Allow for multiple names to match the same virtualhost, for different ports to have different mappings, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org