[
https://jira.jboss.org/jira/browse/ISPN-359?page=com.atlassian.jira.plugi...
]
Vladimir Ralev commented on ISPN-359:
-------------------------------------
By Buddy Replication I meant the DIST mode. I thought it is still called that way. Anyway,
I will see what Brian says about mod_cluster. Other similar products use configurable
affinity key independently in the cache and in the load balancers. In Mobicents we use
pluggable algorithms for example and we will probably try to teach it to cooperate with
this feature deterministically to cover some telco cases (some telco protocols dont have
cookies or redirects to hunt down the right node).
But what is still unclear on this topic is the rehashing/rebalancing. If a node fails is
everything completely re-hashed to a new location (along with the huge network overhead of
moving the chunks around over the network) or is there some effort to minimize the state
transfer?
Provide mechanism for users to control data locality when using DIST
--------------------------------------------------------------------
Key: ISPN-359
URL:
https://jira.jboss.org/jira/browse/ISPN-359
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Cache
Affects Versions: 4.0.0.Final
Reporter: Tero Heinonen
Assignee: Manik Surtani
Fix For: 4.1.0.BETA1
Programmable affinity either through:
1) statically (e.g. annotating a certain field as the key for consistent hashing)
- in our case this cannot be based on the hashCode() as the affinity requirement and
object identity are not directly related
2) dynamically (e.g. providing a overridable/annotatable consistentHashCode() function)
This would help to assign entities (in multiple Caches), which are needed together in the
same nodes (to avoid remote lookups)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira