ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitriy Setrakyan (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-3222) IgniteCache.invokeAll for all cache entries
Date Thu, 02 Jun 2016 16:01:59 GMT

    [ 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:01 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(..)}}. 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.


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)

Mime
View raw message