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. > > > > > >
