Re: [infinispan-dev] Switch to AffinityPartitioner by default, or even enforce it
First, a question: doesn't query already configure its internal caches
to use the AffinityPartitioner? Does it need the application caches to
have AffinityPartitioner enabled, too?
I'm ok with making AffinityPartitioner the default key partitioner:
the less configuration the user has to change to make things work, the
better. I'm also ok with changing it to use delegation, to make it
easy for user to compose it with another key partitioner. We should
just run some benchmarks first to check it doesn't affect performance
for repl mode reads.
But I feel users should be able to disable it if they want to, so I
wouldn't always wrap user partitioners. Also, usually less magic ==
better. Query can validate the configuration and warn the user if the
configuration doesn't have AffinityPartitioner in place.
Cheers
Dan
On Thu, Aug 18, 2016 at 3:43 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
Hi all,
I would like for Infinispan to use the AffinityPartitioner by default,
replacing the HashFunctionPartitioner.
This should have zero impact as AffinityPartitioner extends
HashFunctionPartitioner and only changes semantics when a key is
implementing AffinityTaggedKey.
So the difference would be that for those using AffinityTaggedKey,
these would work out of the box without having to change the
configuration as well.
WDYT?
As a further but separate improvement, I'd change the
AffinityPartitioner to use delegation to the HashFunctionPartitioner
instead of extending it, and always wrap any user configured
partitioner with the AffinityPartitioner.
This would ensure that AffinityTaggedKey work as expectedf even when
people experiment with other partitioners, and avoids some complexity
of configuring Infinispan:
"oh, I didn't know that changing hashing function would break feature
[x]..."
For the record, we're using AffinityTaggedKey in our evil plans to
improve query performance, but it's also sparked interest as a very
useful function by the HACEP team.
I have patches ready...
Thanks,
Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev