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 <[email protected]> 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 <[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. > >>>>>> > >>>>> > >>>> > >>> > >> > >
