Here are the two primary use cases I'm considering:
1. Multiple distinct installations and/or domains of GlassFish are being
operated on a server, with the intent to have one domain use one network
and another use another network. For a particular DAS or instance, all
of the ports for that instance are bound to the same host name.
2. A server with multiple networks, e.g., a front-end network for web
requests, a back-end administrative network, and a back-end database
network. The HTTP/S listeners are bound to the front-end network, while
the admin-listener, GMS traffic, etc. is bound to the administrative
network. Presumably in this case, the nodes would be defined to use the
administrative network.
In both cases, the nodehost can be defined to be the appropriate hostname.
You make a good point regarding binding and connecting.
Tom
On 8/9/2010 12:49 PM, Joe Di Pol wrote:
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>