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