Val, Sure, we can, but we'd like to use map/reduce without fearing that topology can change.
On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Anton, > > You can call affinityCallAsync multiple times and then reduce locally. > > -Val > > On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov < > avinogra...@gridgain.com> > wrote: > > > Val, > > > > > What is the use case for which current affinityRun/Call API doesn't > work? > > It does not work for map/reduce. > > > > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Maxim, > > > > > > The issue is that it's currently assumed to support job mapping, but it > > > actually doesn't. However, I agree that AffinityKeyMapped annotation > > > doesn't fit the use case well. Let's fix documentation and JavaDoc > then. > > > > > > As for the proposed API, it's overcomplicated, took me 15 minutes to > > > understand what it does :) > > > > > > What is the use case for which current affinityRun/Call API doesn't > work? > > > > > > -Val > > > > > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim <dreamx....@gmail.com> > > > wrote: > > > > > > > Valentin, > > > > > > > > The author of tiket wants to see to provide some API allows to map > > > > ComputeJobs to partitions or keys. If we use @AffinityKeyMapped then > > you > > > > need to enter the cache name parameter, I think this is not > convenient > > > for > > > > the user. Therefore, I propose to extend the existing API. > > > > Having consulted with Anton V. decided to make a separate interface > > > > ReducibleTask, which will allow us to have different map logic at > each > > > > inheritor. > > > > > > > > Old method, allows to map to node > > > > public interface ComputeTask<T, R> extends ReducibleTask<R> { > > > > @Nullable public Map<? extends ComputeJob, ClusterNode> > > > > map(List<ClusterNode> subgrid, @Nullable T arg) throws > IgniteException; > > > > } > > > > > > > > Brand new method with mapping to partitions, which solves topology > > change > > > > issues. > > > > public interface AffinityComputeTask<T, R> extends ReducibleTask<R> { > > > > @Nullable public Map<? extends ComputeJob, Integer> > > > map(@NotnullString > > > > cacheName, List<Integer> partIds, @Nullable T arg) throws > > > IgniteException; > > > > } > > > > > > > > public interface ReducibleTask<R> extends Serializable { > > > > public ComputeJobResultPolicy result(ComputeJobResult res, > > > > List<ComputeJobResult> rcvd) throws IgniteException; > > > > > > > > @Nullable public R reduce(List<ComputeJobResult> results) throws > > > > IgniteException; > > > > } > > > > > > > > We also need to implement AffinityComputeTaskAdapter and > > > > AffinityComputeTaskSplitAdapter, for implementation by default. It > is > > > > right? > > > > > > > > In the IgniteCompute add: > > > > > > > > @IgniteAsyncSupported > > > > public <T, R> R affinityExecute(Class<? extends > AffinityComputeTask<T, > > > R>> > > > > taskCls, List<Integer> partIds, @Nullable T arg) throws > > IgniteException; > > > > @IgniteAsyncSupported > > > > public <T, R> R affinityExecute(AffinityComputeTask<T, R> task, > > > > List<Integer> partIds, @Nullable T arg) throws IgniteException; > > > > > > > > public <T, R> ComputeTaskFuture<R> affinityExecuteAsync(Class<? > extends > > > > AffinityComputeTask<T, R>> taskCls, List<Integer> partIds, @Nullable > T > > > arg) > > > > throws IgniteException; > > > > public <T, R> ComputeTaskFuture<R> affinityExecuteAsync( > > > AffinityComputeTask<T, > > > > R> task, List<Integer> partIds, @Nullable T arg) throws > > IgniteException; > > > > > > > > > > > > How do you like this idea or do you insist that you need to use > > > > @AffinityKeyMapped to solve the problem? > > > > > > > > > > > > > 13 июля 2017 г., в 6:36, Valentin Kulichenko < > > > > valentin.kuliche...@gmail.com> написал(а): > > > > > > > > > > Hi Max, > > > > > > > > > > This ticket doesn't assume any API changes, it's about broken > > > > > functionality. I would start with checking what tests we have > > > > > for @AffinityKeyMapped and creating missing one. From what I > > understand > > > > > functionality is broken completely or almost completely, so I guess > > > > testing > > > > > coverage is very weak there. > > > > > > > > > > -Val > > > > > > > > > > On Wed, Jul 12, 2017 at 4:27 PM, Kozlov Maxim < > dreamx....@gmail.com> > > > > wrote: > > > > > > > > > >> Igniters, > > > > >> > > > > >> jira: https://issues.apache.org/jira/browse/IGNITE-5037 < > > > > >> https://issues.apache.org/jira/browse/IGNITE-5037> > > > > >> How do you look to solve this ticket by adding two methods to the > > > public > > > > >> IgniteCompute API? > > > > >> > > > > >> @IgniteAsyncSupported > > > > >> public void affinityRun(@NotNull Collection<String> cacheNames, > > > > >> Collection<Object> keys, IgniteRunnable job) > > > > >> throws IgniteException; > > > > >> > > > > >> @IgniteAsyncSupported > > > > >> public <R> R affinityCall(@NotNull Collection<String> cacheNames, > > > > >> Collection<Object> keys, IgniteCallable<R> job) > > > > >> throws IgniteException; > > > > >> > > > > >> There is also a question of how to act when changing the topology > > > during > > > > >> the execution of the job. > > > > >> 1) complete with an exception; > > > > >> 2) stop execution and wait until the topology is rebuilt and > > continue > > > > >> execution; > > > > >> > > > > >> I think the second way, do you think? > > > > >> > > > > >> -- > > > > >> Best Regards, > > > > >> Max K. > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > -- > > > > Best Regards, > > > > Max K. > > > > > > > > > > > > > > > > > > > > > > > > > >