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 >
