The basic plan for IIOP failover is to fetch the current IIOP port
information for the cluster
from the config objects (basically domain.xml) whenever the ORB is
notified by GMS that
an instance in the cluster has gone down, come back up, or been added
or deleted to the
cluster. In order to do this, I need to understand exactly how the
port information is
represented in GF 3.1.
I think this is similar to the GF 2.x structure, except that there the
GMSLifeCycle code
(in addIIOPEndPoints) added the endpoint info to the GMS distributed
cache. In discussions
with Joe Fialli, we realized that this step is redundant, since the
config object will be
updated before the ORB is notified by GMS about a change in the cluster
status.
So the ORB can update the ports that go into the IOR simply by fetching
the appropriate
config objects.
We have the following structure in the config objects:
- (1)Domain
- (*)Cluster (name, config-ref)
How do I determine which cluster (name attribute?) applies to the
current node?
Will it be possible to configure than one cluster configured in GF 3.1?
Assuming I know this, the config-ref and the server-refs give me the
appropriate Server and Config
objects that I need from Servers and Configs, respectively.
I think I can get the Habitat by injection, then get the top-level
admin objects by
Habitat.getComponent for Domain, Clusters, Servers, and Configs.
I can get a Server using Servers.getServer(String),
a Cluster by looking in the getCluster() list (is there a cluster name
or something else to
identify a particular cluster?), and a Config from
Configs.getConfigByName.
- (1)Domain
- (*)IiopListener (port, id, address) where port is
typically ${some property name}
- The ORB needs the port and id (to determine SSL/clear
etc) and the node address from the server: the address here is the
listener address, not the address used in the IOR
Once I have the correct config, the IiopListener port needs to be
resolved in the context of a
particular Server, since the port value is a property name. I think I
can do this with an
org.glassfish.config.support.PropertyResolver, but that still seems to
require code for parsing
${...}. Is there a utility somewhere that handles this?
I'm trying to piece this together from the source code and whatever
examples I can find.
GF admin is like a trackless wilderness with no maps for those of us
that seldom visit that
part of the code. Please comment on the above, and help me to correct
any errors or
misconceptions that I may have.
Thanks,
Ken.