[infinispan-dev] [infinispan-internal] Unstable Cluster

[Bela Ban]

On 3/6/13 1:33 PM, Dan Berindei wrote:
> On Tue, Mar 5, 2013 at 6:04 PM, Bela Ban <bban at redhat.com
> <mailto:bban at redhat.com>> wrote:
>
>
>
>     On 3/5/13 3:30 PM, Erik Salter wrote:
>      > Hi guys,
>      >
>      > Keep in mind that some of your customers may have built queries
>     and indexes
>      > on cluster names on top of very expensive analytics engines.
>
>
>     Well, if they use their own naming (JChannel.setName()), no problem.
>
>
> Bela, you mean GlobalConfiguration.transport().nodeName(), right? :)


Probably, yes


>     But I've said (many times) that relying on node names is a *bad thing* !
>     Node names are syntactic sugar, and there may not be a name associated
>     with a node, and then it has to be fetched dynamically, using an ARP
>     like protocol.
>
>
> So if a thread logging the name of a node it may trigger an "RPC" and
> it'll block until it gets a response?
> That doesn't sound right...


No, this is only done for the UUID/physical-address mapping, but not for 
the logical name.


>     If someone wanted to add information to an address, then the way to do
>     it would be to use an AddressGenerator and return subclasses of UUID,
>     e.g. PayloadUUID.
>
>
> I think Erik just wants the logs to contain the actual host names, so
> that they match with the logs from other sources. Using a PayloadUUID
> and sending the host name with every message would be overkill for that.


Fair enough - with the caveat that the logical name *may* not always be 
available, e.g. if you start many nodes concurrently. If he can work 
with this, or around it, no problem. Yes, using the logical name causes 
no overhead for every address, contrary to PayloadUUID.


-- 
Bela Ban, JGroups lead (http://www.jgroups.org)