[jboss-dev] Public IP address used by JBoss AS

[Brian Stansberry]

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