On Thu, Apr 6, 2017 at 2:52 AM, Alexey Goncharuk wrote:
> Yes, this can happen if caches were created on different versions of
> topology, because FairAffinityFunction is stateful and requires previous
> affinity assignment state.
>
In this case we have to add validation for dynamically started
gt;
> >
> >
> > --
> > View this message in context: http://apache-ignite-
> > developers.2346864.n4.nabble.com/Non-collocated-
> > distributed-SQL-Joins-across-caches-over-separate-cluster-
> > groups-tp16136p16163.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
> >
>
> distributed-SQL-Joins-across-caches-over-separate-cluster-
> groups-tp16136p16163.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>
I suggest we continue the conversation on the user list. My bad for pinging
the email to both channels.
--
View this message in context:
http://apache-ignite-developers.2346864.n4.nabble.com/Non-collocated-distributed-SQL-Joins-across-caches-over-separate-cluster-groups-tp16136p16163.html
Sent
Sergi,
Does it means that "broken" FairAffinityFunction can lead to wrong SQL
query result?
As we know, using FairAF have no guarantee that same parititions of
different caches can belongs to different nodes in some cases.
On Wed, Apr 5, 2017 at 1:47 PM, Sergi Vladykin
wrote:
> Hi,
>
> Moreover
Hi,
Moreover distributed joins can be executed only between caches with the
same affinity (same partitions on the same nodes).
Keep in mind that distributed join is already a "last resort" thing and you
have to prefer collocated joins as much as possible, if you want to achieve
good performance.
Igniters,
Is it correct to assume the following:
We have an Ignite cluster comprised of 2 cluster groups A & B that have
different caches deployed.
We use an Ignite client to obtain API access to the whole cluster and execute a
join query that joins data across the 2 caches
My understanding is
