Val, A fundamental problem with sending computes to data is that the computes can be buggy. We have a set of constantly changing read-only analytics we want to run and caches where readFromBackup is set.
If a bug is introduced where the closure goes into an infinite loop, or consumes all the memory on all nodes it is sent to, we would like that to be constrained so that if we lose all those nodes, we still have a full copy of the data on the remaining. We have implemented the simple affinityBackupFunction which forces the primary and backup to different sets of nodes (availability zones) on a partition basis, so that no partition has all of its replicas in the same group of nodes. If I use IgniteCompute.Broadcast(), then the execution will be localized to the cluster group. However, if I have use cases that want to sent many closures to execute near a local copy of the data, I'd like to constraint them in the same way. I can use the Affinity interface to determine the node that currently has the key, and send a closure there, but the semantics of affinityRun.. are what I really would like. "The data of the partition where affKey is stored will not be migrated from the target node while the job is executed." The semantics of this case should be clear, and they are not. The code should be changed to alter the behavior if the primary node is not in the subgrid. It should not depend on lower layers detecting and handling a case it should not have been allowed through. If the primary and backups are not in the subgrid, then throw an exception. I would not consider the case of code that depends on the current behavior important. The interesting question is about cost/benefit of defining this as "use a backup in the subgrid if the the primary is not in the subgrid". The primary question on cost is if we did choose a backup node because the primary was not in the grid, would it just work, or would there be ripple effects at lower layers? My hope is that we can do a change of modest benefit with low cost, which could end up being to change the documentation to say not to do this.... Thanks, -DH On Fri, Aug 31, 2018 at 2:15 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Dave, > > In case it's executed even if primary node is outside of the cluster group, > then I think it's a bug - I would throw an exception in this case. However, > is there any particular reason you're doing this? Is there a use case? I > don't see much sense in combining affinityRun with a cluster group. > > Backup no node is never used by affinityRun to my knowledge. > > -Val > > On Fri, Aug 31, 2018 at 7:07 AM David Harvey <syssoft...@gmail.com> wrote: > > > This function takes: > > > > int partId, > > > > ... > > > > @Nullable Collection<ClusterNode> nodes, > > > > > > It uses partId to find the node with the primary partition, and proceeds > > even if that node is not in the subgrid that was passed in. This is > either > > a bug, or the semantics should be specified more clearly. > > > > > > There are two sub-cases. > > > > > > - one of nodes in the sub-grid is a backup for the partition > > - the partition does not exist on any of the nodes in the sub-grid > > > > This case can be exposed via IgnuteCompute.affinityRun... when the > > IgniteCompute was created with a subgrid that did not include the primary > > node. > > > > I got lost tracing the code below this, and could not tell if this would > > throw an exception or execute on the primary node. The later would seem > > to just be a bug. It would be simple to change this code to choose a > node > > in the subgrid or throw and exception. > > > > If it selected a backup node, then would the this part of the > IgniteCompute > > contract still hold w/o other changes: "The data of the partition where > > affKey is stored will not be migrated from the target node while the job > is > > executed." ? > > > > In any case, the IgniteCompute semantics around this case should be > stated. > > > > > > -DH > > >
