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