Hi Ken,
I added comments below to your original email questions.
Jennifer
On 7/6/2010 11:14 PM, Ken wrote:
> Joseph Fialli wrote:
>> Ken,
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=12397
>>
>> I would recommend that you push for this to be fixed for M3.
>>
>> -Joe
>>
> Is there really a problem here? What I need to do is resolved the
> values of the port
> in the config element in the context of the appropriate server object
> (using something
> like PropertyResolver), so that the SystemProperty instances in the
> server are applied
> to the port value (see the attached email).
>
> From the bug, it looks like GF 3.1 will support multiple clusters in
> domain.xml.
> So how do I determine which cluster my instance is running in? I
> think I've got
> a lot of this figured out, but I'm still waiting to here from the
> admin team about
> the first email message.
>
> Thanks,
>
> Ken.
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Understanding IIOP port configuration in clusters
> From:
> Ken <ken.cavanaugh_at_oracle.com>
> Date:
> Tue, 06 Jul 2010 11:04:02 -0700
> To:
> admin_at_glassfish.dev.java.net
>
> To:
> admin_at_glassfish.dev.java.net
> CC:
> corba-dev <corba-dev_at_Sun.COM>
>
>
> 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
> o (1)Clusters
> + (*)Cluster (name, config-ref)
> # (*)Server (ref)
> * (*)SystemProperty
>
> How do I determine which cluster (name attribute?) applies to the
> current node?
On Domain you can call - Cluster getClusterForInstance(String instanceName);
or
call getCluster on Server
> Will it be possible to configure than one cluster configured in GF 3.1?
yes
> 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),
You can do this inject to get the currently running Server and then get
Cluster and Config.
@Inject(name=ServerEnvironment.DEFAULT_INSTANCE_NAME)
private Server server;
Or inject Domain and work down from there.
> a Cluster by looking in the getCluster() list (is there a cluster name
> or something else to
> identify a particular cluster?)
yes - there is getName on Cluster
> , and a Config from Configs.getConfigByName.
>
> * (1)Domain
> o (1)Configs
> + (*)Config
> # (1)IiopService
> * (*)IiopListener (port, id, address)
> where port is typically ${some property
> name}
> o 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?
PropertyResolver does this already - it will look for the property name
that is defined inside ${....}.
>
> 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.
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>