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 <[email protected]> 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 <[email protected]>: > >> Affinity run/call operate on a single key AFAIK. >> >> On Mon, May 30, 2016 at 10:55 PM, Dmitriy Setrakyan <[email protected] >>> >> 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 <[email protected]> >>> 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 < >>> [email protected]> >>>> 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 < >>> [email protected]> >>>>> 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. >>>>>> >>>>> >>>> >>> >>
