ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: GridClosureProcessor.affinityRun() semantics
Date Fri, 31 Aug 2018 18:15:02 GMT

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.


On Fri, Aug 31, 2018 at 7:07 AM David Harvey <syssoftsol@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message