Denis, thank you, this may work, but:
* it is too complicated
* it does not guarantee locality

This seems to be a common task, why don't we implement invokeAll as I
suggested above?

On Tue, May 31, 2016 at 1:05 PM, Denis Magda <dmagda@gridgain.com> wrote:

> Pavel,
>
> Here is an example on how to execute scan queries on partitions’ owners
> and perform some operation for every entry
>
> https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/datagrid/query/ScanQueryExample.java
> <
> https://github.com/gridgain/gridgain-advanced-examples/blob/master/src/main/java/org/gridgain/examples/datagrid/query/ScanQueryExample.java
> >
>
> When this feature is implemented [1] it will be possible to postpone
> partitions movement until such an operation is in progress. Presently if
> the rebalancing happens the data will be retrieved from a remote node (new
> partition owner), however the result will be consistent in any case.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-2310 <
> https://issues.apache.org/jira/browse/IGNITE-2310>
>
> —
> Denis
>
> > On May 31, 2016, at 7:42 AM, Yakov Zhdanov <yzhdanov@gridgain.com>
> wrote:
> >
> > Vova, even though it operates on single key we will need to "pin"
> partition
> > so key does not go to another node.
> >
> > Pavel, you can also send closures to all primary nodes to do local scan
> > query for each partition. This way you will go over each entry.
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2016-05-30 16:05 GMT-04:00 Vladimir Ozerov <vozerov@gridgain.com>:
> >
> >> Affinity run/call operate on a single key AFAIK.
> >>
> >> On Mon, May 30, 2016 at 10:55 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> >>>
> >> wrote:
> >>
> >>> Actually I have seen a ticket to block moving partitions if
> affinityCall
> >> or
> >>> affinityRun are called. I think once these tickets are implemented, the
> >>> process will become reliable, no?
> >>>
> >>> D.
> >>>
> >>> On Mon, May 30, 2016 at 9:13 AM, Pavel Tupitsyn <
> ptupitsyn@gridgain.com>
> >>> wrote:
> >>>
> >>>> Dmitriy, as I understand, there is no reliable way to do that if
> >>>> rebalancing happens.
> >>>>
> >>>> On Mon, May 30, 2016 at 6:50 PM, Dmitriy Setrakyan <
> >>> dsetrakyan@apache.org>
> >>>> wrote:
> >>>>
> >>>>> I think we do support this use case. Why not send a computation to a
> >>>> server
> >>>>> and then perform the iteration through the cache entries locally on
> >>> that
> >>>>> server?
> >>>>>
> >>>>> On Mon, May 30, 2016 at 4:44 AM, Pavel Tupitsyn <
> >>> ptupitsyn@gridgain.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Igniters,
> >>>>>>
> >>>>>> Looks like we do not have an efficient way to perform an action on
> >>>> EVERY
> >>>>>> cache entry.
> >>>>>>
> >>>>>> Let's say I want to remove all entries that match a predicate.
> >>>>>> My only option is to retrieve these entries via Scan or SQL query,
> >>> and
> >>>>> then
> >>>>>> call removeAll.
> >>>>>> This involves a lot of unnecessary network trips (send keys to
> >> caller
> >>>>> node,
> >>>>>> send them back to primary nodes).
> >>>>>>
> >>>>>> Would it be possible to implement a method like
> >>>>>> void IgniteCache.invokeAll(entryProcessor)
> >>>>>> that invokes the processor on all entries and does not return
> >>> anything?
> >>>>>> There could be more overloads that return results or only return
> >>>> results
> >>>>>> for changed entries.
> >>>>>>
> >>>>>> Thoughts?
> >>>>>>
> >>>>>> Pavel.
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>