Re: [jboss-dev] Public IP address used by JBoss AS
On 05/26/2010 12:53 PM, Andrew Lee Rubinger wrote:
On 05/26/2010 01:45 PM, Brian Stansberry wrote:
> On 05/26/2010 11:43 AM, Andrew Lee Rubinger wrote:
>> On 05/26/2010 12:09 PM, Bela Ban wrote:
>>> Brian Stansberry wrote:
>>>> IMO we would *not* allow these values as a general configuration
>>>> option, e.g. in a -jboss-beans.xml:
>>>>
>>>> <!-- Not supported -->
>>>> <property name="bindAddress">PUBLIC</property>
>>>
>>> -100 IMO: a user may want to define an address based on some criteria,
>>> so the above makes perfect sense ! I can even envisage that we support
>>> something like this later:
>>>
>>> <property
name="bindAddress">192.168.*,274.2.*,SITE_LOCAL</property>,
>>>
>>> which means that we should try to pick a site local address starting
>>> with 192.168, if not found a global IP address starting with 274.*, and
>>> if still not found, go and grab any site local address.
>>>
>>> All of this logic can be centralized (in JGroups it is in 1 place) and
>>> used everywhere.
>>
>> If we put the resolution logic inside of jboss-bootstrap, any MC
>> component can @Inject or<inject> the JBossASConfiguration and do
>> getBindAddress() (even if the input was something like "PUBLIC"). The
>> configuration initialization phase would resolve before the server
>> comes up.
>>
>
> If the goal is fine grained configuring what type of interface an
> interface uses, then the closest mapping to:
>
> <property name="bindAddress">PUBLIC</property>
>
> is
>
> <property name="bindAddress"><inject
bean="JBossASConfiguration"
> property="publicAddress"/></property>
>
> So that implies new properties in JBossASConfiguration.
Is that true?
Why not allow input of bindAddress=="PUBLIC", which may resolve to
201.23.2.100 within the same property? Do we need to hang on to the
inputs or just resolve them to a real jboss.bind.address? So then it'd be:
<property name="bindAddress"><inject
bean="JBossASConfiguration"
property="bindAddress"/></property>
...which we already have.
That leaves you with only one address. It doesn't support the equivalent
of the following for some service or combination of services:
<property name="externalAddress">PUBLIC</property>
<property name="intraClusterAddress">SITE_LOCAL</property>
The need for that kind of flexibility is the argument for being able to
resolve PUBLIC et al at any injection point.
>
> Since this is really an API discussion, I'd still like to hear more
> about what the real world use cases are. I get the one where a server
> listens on interface X for external requests and uses interface Y for
> internal to the cluster traffic. I can dream up others. What other ones
> are actually used?
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat