[
https://issues.apache.org/jira/browse/IGNITE-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312537#comment-15312537
]
Dmitriy Setrakyan commented on IGNITE-3222:
-------------------------------------------
> 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?
I don't think it is a common task at all. On top of that, if partition-based
affinityCall/Run can achieve the same goal, I don't see a need for an
additional API that can do the same thing. I am also, generally, against having
methods that can potentially return the whole cache to the client side.
> What kind of memory issues do you expect? Returning EntryProcessorResult for
> each entry on a huge cache is an obvious problem, same as calling getAll on
> QueryCursor, for example. We can't protect users from such things.
It is not the same as {{getAll(..)}}. User must pass the keys into
{{getAll(...)}} method and is aware how many entries will be returned. In this
case, you can get millions of entries back, which will certainly cause memory
issues. To do this right, we have to paginate the result, which will complicate
the API and the overall implementation of this task.
> IgniteCache.invokeAll for all cache entries
> -------------------------------------------
>
> Key: IGNITE-3222
> URL: https://issues.apache.org/jira/browse/IGNITE-3222
> Project: Ignite
> Issue Type: Task
> Components: cache
> Affects Versions: 1.1.4
> Reporter: Pavel Tupitsyn
> Fix For: 1.7
>
>
> Implement an invokeAll overload that processes all cache keys (not some
> specific set).
> Proposed signature:
> {code}
> public void invokeAll(CacheEntryProcessor<K, V, T> entryProcessor, Object...
> args);
> public <T> Map<K, EntryProcessorResult<T>> invokeAll(CacheEntryProcessor<K,
> V, T> entryProcessor, boolean returnAffectedOnly, Object... args);
> {code}
> This will apply the specified processor to all cache entries.
> First method does not return anything.
> Second method either returns all results for all entries, or only for entries
> that have been changed by the processor in any way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
