If I take a step back from GlassFish and generalize this I
see:
Configuration information that defines what hostname(s) the server
should bind to.
Configuration information that defines what hostname clients
should connect to.
In the world of DNS aliases, VIPS, etc these can be different
for your general server.
In our case I think the admin-listener information is the former, and
node-host is the later. The node-host is the hostname that
clients (the DAS) should connect to when they need to do GlassFish
administrative stuff.
So the current behavior seems correct to me. I guess then the question
is should it be optimized for expected GlassFish deployments, like
you propose, to eliminate potential human error.
Are we sure there is not a valid use case where the hostname the DAS
should use to connect to an instance is different from the hostname
the admin-listener is bound to (other than the 0.0.0.0 case)?
Joe
Tom Mueller wrote:
> I'm working on issue 12666, which is to make sure that the DAS and
> clustering will work on a multi-address server, i.e., a server with
> multiple NICs. It is possible to get this to work, but there is some
> questionable behavior regarding command replication and commands that
> invoke commands on instances. I'd like to get some input as to whether
> this questionable behavior needs to be fixed.
>
> As an example, consider the list-instances command. This command runs
> __locations and uptime on each instance. It gets the server name for
> the instance by calling Server.getHost, which looks up the nodehost
> attribute for the node element for the server. It never looks at the
> "address" property of the admin-listener to which it is going to
> connect. To get the list-instances command to work correctly in the
> multi-address case, the listeners are configured to bind to a particular
> hostname (rather than 0.0.0.0), so the nodehost for the node for the
> instance has to be set to use the same hostname as the admin-listener
> for that instance. (This is the questionable behavior).
>
> To fix this, we could have Server.getHost look at the admin-listener for
> the host, and if the "address" property is not 0.0.0.0, then return
> that. Otherwise, look at the nodehost value for the node as it does
> currently. Or, we could add a new method, Server.getAdminHost, or we
> could get rid of Server.getHost and have Server.getAdminHost and
> Server.getNodeHost. This all depends on what callers of Server.getHost
> are really expecting to get.
>
> The same problem occurs with command replication. I didn't dig into it,
> but I expect that it is calling Server.getHost also to determine what
> hostname to use in replicating the command. Vijay, can you confirm that
> this is how command replication gets the hostname?
>
> Thoughts?
> Thanks.
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>