[infinispan-dev] [jgroups-dev] Shouldn't Event.GET_PHYSICAL_ADDRESS return a collection PhysicalAddress instances?

[Galder Zamarreno]

Here: 
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/remoting/transport/Transport.java

We don't call that method in TP, we used your suggested solution. See:
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/remoting/transport/jgroups/JGroupsTransport.java

The method exposed in that interface is for sole internal use, it 
provides an abstraction of the Transport. That's why I said that the 
Address returned is our abstraction, or to be more precise:
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/remoting/transport/Address.java

Now, back to the question, do you agree that we made:

    /**
     * Retrieves the current cache instance's phyical network address. 
Some implementations might differentiate
     * between logical and physical addresses in which case, this method 
allows clients to query the physical one.
     * Implementations where logical and physical address are the same 
will simply return the same Address
     * as {@link #getAddress()}.
     *
     * @return an Address
     */
    Address getPhysicalAddress();

Something like this instead?

    Address[] getPhysicalAddresses();

On 12/01/2009 03:49 PM, Bela Ban wrote:
> Where's that method ? There is a getPhysicalAddress() method in TP, but
> it's not supposed to be called. The way to get the physical address is
> via the GET_PHYSICAL_ADDRESS event.
>
> Galder Zamarreno wrote:
>> On 12/01/2009 09:41 AM, Bela Ban wrote:
>>> Brian Stansberry wrote:
>>>> On 11/29/2009 06:40 AM, Bela Ban wrote:
>>>>> This feature has been put on the backburner, I might not even
>>>>> implement
>>>>> it. If I do, then in 3.0, which requires changes anyway.
>>>>>
>>>>> I don't know who's using this event currently, are you guys
>>>>> prepared to
>>>>> change your code if I made this change ?
>>
>> Yes, we are but it might be wise to accomodate that for the future
>> since we have an interface called Transport that currently defines:
>> Address getPhysicalAddress();
>>
>> Where Address is an abstraction of JGroups' Address.
>>
>> So, to make it future proof, it should say:
>> Address[] getPhysicalAddresses();
>>
>> Currently, it would only return one but in the future it would allow
>> us to return more than one.
>>
>>
>>>> AS 6 will use it, as information on the address + port of cluster
>>>> members is part of the public API of the HAPartition framework. My
>>>> understanding was this already exists in JGroups 2.8.
>>>>
>>>> The AS can adapt to changes in this, as it's not part of any release
>>>> yet.
>>>>
>>>> JBC 3.2.1 uses it with buddy replication when JGroups 2.8 is
>>>> integrated,
>>>> to support not choosing a buddy on the same physical machine.
>>> I'll leave the GET_PHYSICAL_ADDR even as is for now, it will always
>>> return the physical address associated with the logical one. Associating
>>> multiple physical addresses will be done in 2.9 or 3.0, or maybe put on
>>> the backburner altogether.
>>>
>>> Should I decide to implement this feature, I can still create a
>>> GET_PHYSICAL_ADDRS (plural) event.
>>
>>
>>
>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache