On 11/29/11 2:10 PM, Galder Zamarreño wrote: > Hi, > > We've been having a discussion this morning with regards to the Hot Rod > changes introduced in 5.1 with regards to hashing. > > When Hot Rod server is deployed in AS, in order to start correctly, it > requires the Hot Rod server to start before any other (clustered) caches in > AS. This is because any hashing can only be done once the hash has been > calculated on the hot rod endpoint. > > Although this can be fixed in a hacky way (have all caches configured to > start lazily and let the Hot Rod server start the topology cache and then all > defined caches, ugh), we're considering a slight change to Hot Rod protocol v > 1.1 > (https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.1) > that would solve this problem. > > Instead of hashing on the hot rod endpoint address (host:port), we could hash > on JGroups's Address UTF-8 toString representation, which is the logical > address. The advantage here is any cache can calculate the hash on this from > the start, no need to wait for Hot Rod server to start. The downside is that > Hot Rod clients need to be aware of this UTF-8 string in order to hash to the > same thing, so it'd mean shipping this back to the clients alongside the hot > rod endpoint info.
I have a few concerns, maybe not an issue with the way HotRod uses this, but I wanted to bring this up anyway: - What if a logical name is null ? A user can do JChannel.setName(null); - What if the logical name changes at runtime ? Certainly not recomended, but the APi allows this, or I should rather say, doesn't prevent it... :-( - What if we have multiple members with the same logical name ? - At startup, we may not yet have the logical names of all members, as this is done as part of the discovery protocol... - Can't you hash on the address ? It'll be available as soon as connect() returns. Is that too late ? Note that you can also generate your own addresses (using AddressGenerator) if that helps... -- Bela Ban Lead JGroups (http://www.jgroups.org) JBoss / Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
