Re: IgniteCache.invoke on ALL keys

I responded in the ticket: https://issues.apache.org/jira/browse/IGNITE-3222 On Thu, Jun 2, 2016 at 2:10 AM, Pavel Tupitsyn wrote: > Dmitriy, affinityCall/Run over a partition is useful, I agree. > > But dealing with partitions manually is also error-prone and not obvious at > all. > Invoke over

Re: IgniteCache.invoke on ALL keys

Dmitriy, affinityCall/Run over a partition is useful, I agree. But dealing with partitions manually is also error-prone and not obvious at all. Invoke over all cache entries is a simple common task, why not provide a simple method of doing it? What kind of memory issues do you expect? Returning E

Re: IgniteCache.invoke on ALL keys

Pavel, I actually believe that such method will be error-prone and will cause all sorts of memory issues for users trying to execute this method over large caches. What we need instead is an affinityCall/Run method over a partition, not a key. Why not provide this method instead? Added my commen

Re: IgniteCache.invoke on ALL keys

Ok then, looks like there are no obstacles or objections, I've created a JIRA ticket: https://issues.apache.org/jira/browse/IGNITE-3222 Thanks, Pavel. On Tue, May 31, 2016 at 3:44 PM, Denis Magda wrote: > Pavel, > > > This seems to be a common task, why don't we implement invokeAll as I > > sug

Re: IgniteCache.invoke on ALL keys

Pavel, > This seems to be a common task, why don't we implement invokeAll as I > suggested above? I would implement such a method using the approach shown in the example. In my understanding it would be the most efficient way. Data locality will longer be not an issue when IGNITE-2310 is implem

Re: IgniteCache.invoke on ALL keys

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 wrote: > Pavel, > > Here is an example on how to execute scan querie

Re: IgniteCache.invoke on ALL keys

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

Re: IgniteCache.invoke on ALL keys

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

Re: IgniteCache.invoke on ALL keys

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

Re: IgniteCache.invoke on ALL keys

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 wrote: > Dmitriy, as I understand, there is no reliable way to

Re: IgniteCache.invoke on ALL keys

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

Re: IgniteCache.invoke on ALL keys

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 wrote: > Igniters, > > Looks like we do not have an efficient way to perform an action on E

IgniteCache.invoke on ALL keys

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 tri