ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: IGNITE-4535 : Add option to store deserialized values on-heap
Date Tue, 04 Apr 2017 16:15:20 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message