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