[
https://issues.apache.org/jira/browse/IGNITE-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15312537#comment-15312537
]
Dmitriy Setrakyan edited comment on IGNITE-3222 at 6/2/16 4:04 PM:
-------------------------------------------------------------------
_> 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(..)}} on {{QueryCursor}}, because the cursor
offers a paginated result by default and user must take a deliberate action to
suck all the results at ones. In your case the whole result set is returned all
the time, 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.
was (Author: dsetrakyan):
_> 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)
