Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CADM=oMafNO8vL_YqCs7hT=XV5+PLZXGB5hiXjiOxriAB=j-8uw@mail.gmail.com>
References: <CADM=oMafNO8vL_YqCs7hT=XV5+PLZXGB5hiXjiOxriAB=j-8uw@mail.gmail.com>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Tue, 4 Apr 2017 09:15:20 -0700
Message-ID: <CA+0=VoU7r-MMYRdjsPP3A4kN24rAdX4vJTE=ZVHFihdzneP_eQ@mail.gmail.com>
Subject: Re: IGNITE-4535 : Add option to store deserialized values on-heap
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a114563fe8db976054c599704
archived-at: Tue, 04 Apr 2017 16:16:05 -0000

--001a114563fe8db976054c599704
Content-Type: text/plain; charset=UTF-8

Ilya, I looked at the Semyon's comments in the ticket, and I think I agree
with him on all counts.

1. Setting an eviction policy should not be a mechanism to enable the
on-heap cache. We already have eviction policies off-heap as well, and they
don't enable anything. On top of that, the eviction policy should not be a
requirement for the on-heap cache. User should still be able to enable the
on-heap cache, even if it grows indefinitely without evictions. We should
have a more intuitive flag here.

2. As far as the tests go, they should examine all the tests and adapt them
to the new behavior. I think we should have a replica of all off-heap tests
to test the scenario with on-heap caches.

D.

On Tue, Apr 4, 2017 at 8:12 AM, Ilya Lantukh <ilantukh@gridgain.com> wrote:

> Hi Igniters,
>
> Since review of IGNITE-4535
> <https://issues.apache.org/jira/browse/IGNITE-4535> implementation caused
> some misunderstandings, I'd like to open a discussion here and see if
> everyone agrees with the chosen approach or can suggest a better one.
>
> We are going to re-use existing EvictionPolicy mechanics to decide when
> entry is going to be evicted from on-heap cache. If evictionPolicy == null,
> we assume that there is no on-heap cache. One of suggested alternatives was
> to have a separate boolean parameter that will enable on-heap cache.
>
> Another questionable decision was to remove tests for memory mode
> variations. For example, we had GridCacheContinuousQueryAtomicSelfTest,
> GridCacheContinuousQueryAtomicOffheapTieredSelfTest and
> GridCacheContinuousQueryAtomicOffheapValuesSelfTest that were testing the
> same functionallity for ONHEAP_TIERED, OFFHEAP_TIERED and OFFHEAP_VALUES
> modes, respectively. Since those memory modes were removed, only
> GridCacheContinuousQueryAtomicSelfTest was left and it now runs in
> off-heap
> mode without on-heap cache. One of suggestions was to add a new subclass to
> this test (and all other tests) that will run the same test case with
> on-heap cache enabled. In my opinion, functionallity that is specific for
> on-heap cache should be tested in completely separate tests (which we
> already have), and there is no need to run generic tests with every
> possible configuration.
>
> What do you think?
>
> --
> Best regards,
> Ilya
>

--001a114563fe8db976054c599704--