Here:
https://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/i...
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/i...
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/i...
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