What??? Unbelievable. It sounds like a design flaw to me. Any ideas how to fix?
—
Denis
> On Mar 2, 2017, at 2:43 PM, Valentin Kulichenko
> wrote:
>
> Adding back the dev list.
>
> Folks,
>
> Are there any opinions on the problem discussed here? Do we really need
> FairAffinityFunction if i
Adding back the dev list.
Folks,
Are there any opinions on the problem discussed here? Do we really need
FairAffinityFunction if it can't guarantee cross-cache collocation?
-Val
On Thu, Mar 2, 2017 at 2:41 PM, vkulichenko
wrote:
> Hi Alex,
>
> I see your point. Can you please outline its adva
Crossposting to dev list.
I've made a test.
It looks ok for Rendevouz A, partition distribution for caches with
similar settings and same Rendevouz AF keep same.
But FairAF partition distribution can differed for two caches that one was
created before and second - after rebalancing.
So, collocat
Hi.
As I investigated the issue occurs when different nodes creates the caches.
Say I have 2 nodes node1 and node2 and 2 caches cache1 and cache2. If I
create cache1 on node1 and create cache2 on node2 with same
FairAffinityFunction with same partition size, keys can map different nodes
on differ
Hi.
Thanks for your comments. Let me investigate the issue deeper.
Regards.
On Thu, Feb 23, 2017 at 11:00 PM, Dmitriy Setrakyan
wrote:
> If you use the same (or default) configuration for the affinity, then the
> same key in different caches will always end up on the same node. This is
> guara
If you use the same (or default) configuration for the affinity, then the
same key in different caches will always end up on the same node. This is
guaranteed.
D.
On Thu, Feb 23, 2017 at 8:09 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:
> Val,
>
> Yes, with same affinity function en
Val,
Yes, with same affinity function entries with same key should be saved in
same nodes.
As far as I know, primary node is assinged automatically by Ignite. And I'm
not sure that
there is a guarantee that 2 entries from different caches with same key
will have same primary and backup nodes.
So,
Actually, this should work this way out of the box, as long as the same
affinity function is configured for all caches (that's true for default
settings).
Andrey, am I missing something?
-Val
On Thu, Feb 23, 2017 at 7:02 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:
> Hi Alper,
>
>
Hi Alper,
You can implement you own affinityFunction to achieve this.
In AF you should implement 2 mappings: key to partition and partition to
node.
First mapping looks trivial, but second doesn't.
Even if you will lucky to do it, there is no way to choose what node wil be
primary and what will b
