Mailing-List: contact issues-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Date: Thu, 2 Jun 2016 16:01:59 +0000 (UTC)
From: "Dmitriy Setrakyan (JIRA)" <jira@apache.org>
To: issues@ignite.apache.org
Message-ID: <JIRA.12974218.1464700571000.16292.1464883319257@Atlassian.JIRA>
In-Reply-To: <JIRA.12974218.1464700571000@Atlassian.JIRA>
References: <JIRA.12974218.1464700571000@Atlassian.JIRA> <JIRA.12974218.1464700571680@arcas>
Subject: [jira] [Comment Edited] (IGNITE-3222) IgniteCache.invokeAll for all
 cache entries
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 02 Jun 2016 16:02:01 -0000


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