Hi Sanne, An alternative approach would be to implement an org.infinispan.commons.hash.Hash which delegates to the stock implementation for all keys except those that need to be assigned to a specific segment. It should return the desired segment for those.
Adrian On 01/20/2015 02:48 AM, Sanne Grinovero wrote: > Hi all, > > I'm playing with an idea for some internal components to be able to > "tag" the key for an entry to be stored into Infinispan in a very > specific segment of the CH. > > Conceptually the plan is easy to understand by looking at this patch: > > https://github.com/Sanne/infinispan/commit/45a3d9e62318d5f5f950a60b5bb174d23037335f > > Hacking the change into ReplicatedConsistentHash is quite barbaric, > please bear with me as I couldn't figure a better way to be able to > experiment with this. I'll probably want to extend this class, but > then I'm not sure how to plug it in? > > What would you all think of such a "tagging" mechanism? > > # Why I didn't use the KeyAffinityService > - I need to use my own keys, not the meaningless stuff produced by the service > - the extensive usage of Random in there doesn't seem suited for a > performance critical path > > # Why I didn't use the Grouping API > - I need to pick the specific storage segment, not just co-locate with > a different key > > > The general goal is to make it possible to "tag" all entries of an > index, and have an independent index for each segment of the CH. So > the resulting effect would be, that when a primary owner for any key K > is making an update, and this triggers an index update, that update is > A) going to happen on the same node -> no need to forwarding to a > "master indexing node" > B) each such writes on the index happen on the same node which is > primary owner for all the written entries of the index. > > There are two additional nice consequences: > - there would be no need to perform a reliable "master election": > ownership singleton is already guaranteed by Infinispan's essential > logic, so it would reuse that > - the propagation of writes on the index from the primary owner > (which is the local node by definition) to backup owners could use > REPL_ASYNC for most practical use cases. > > So net result is that the overhead for indexing is reduced to 0 (ZERO) > blocking RPCs if the async repl is acceptable, or to only one blocking > roundtrip if very strict consistency is required. > > Thanks, > Sanne > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
