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: <CAMegbcLzJ9W=NXsVRAh6KsROpO=5-egmsCLEEP7Uxr-aTB0y2g@mail.gmail.com>
References: <1462861575784-4853.post@n6.nabble.com> <CAMegbc+XVO8+4DOHPzgdshecX68oRXH03SfSeo1wYJo=DOxuHw@mail.gmail.com>
 <CAEOB7kXJo-Dgv_6FDTE+nPEE-DAwcTQ4Y_UoqSs7gEnPJ6c90g@mail.gmail.com> <CAMegbcLzJ9W=NXsVRAh6KsROpO=5-egmsCLEEP7Uxr-aTB0y2g@mail.gmail.com>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Mon, 16 May 2016 17:44:40 -0700
Message-ID: <CA+0=VoWz6yGR-xMa2HEYvrka9V1oiFd3x6Nesu2k5qrTtPTtXQ@mail.gmail.com>
Subject: Fwd: Eviction Events with offheap values
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a11353aaa3400760532ff0e8f
archived-at: Tue, 17 May 2016 00:45:23 -0000

--001a11353aaa3400760532ff0e8f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Guys,

Resending this question to the dev list. Doesn=E2=80=99t Ignite fire an evi=
ction
event whenever an entry is evicted from off-heap memory?

D.

---------- Forwarded message ----------
From: Alexei Scherbakov <alexey.scherbakoff@gmail.com>
Date: Mon, May 16, 2016 at 1:33 AM
Subject: Re: Eviction Events with offheap values
To: user@ignite.apache.org


Andrey, thanks for the clarification.

Abraham, it seems EvictionPolicy is not appropriate solution for your case.
BTW, why user session expiration logic is related to cache size ?
In case user sessions expire by timeout the more appropriate solution would
be listening to
EVT_CACHE_OBJECT_EXPIRED event.
You can also set eager expiration by calling
CacheConfiguration.setEagerTtl(true)
to make Ignite expire values automatically.

Did this help?


2016-05-13 19:49 GMT+03:00 Andrey Gura <agura@gridgain.com>:

> Alexei, Abraham,
>
> Eviction policy configuration doesn't make sense for OFFHEAP_TIERED mode.
> Eviction policy works only for on heap entries in order to evict entries =
to
> offheap.
>
> For eviction of entries from offheap memory Ignite internaly uses other
> LRU eviction policy and there is no way to change this behaviour via
> configuration.
>
> On Thu, May 12, 2016 at 7:14 PM, Alexei Scherbakov <
> alexey.scherbakoff@gmail.com> wrote:
>
>> Hi,
>>
>> I was not able to reproduce your case.
>> In my test I have correct old value on eviction event.
>> Please provide a reproducer.
>>
>> BTW: what are you trying to accomplish? Generally events are not very
>> good for cluster performance and may not be delivered in case of the
>> listener node failure.
>>
>> 2016-05-10 9:26 GMT+03:00 abraham <a.mueller@qriously.com>:
>>
>>> Hi,
>>>
>>> I am re-posting an earlier message to which I did not get any replies
>>> because I was not subscribed to the mailing list:
>>>
>>> I am trying to get the values from the eviction events. This works fine
>>> with
>>> the ONHEAP_TIERED version but not with OFFHEAP_VALUES and OFFHEAP_TIERE=
D
>>> -
>>> in that cases the hasOldValue is true but the actual value is null.
>>>
>>> What we are trying to accomplish is to persist entries to a database on=
ly
>>> when they either get removed, expired or evicted because the max cache
>>> size
>>> is reached and it looks like those events are the only way to accomplis=
h
>>> this.
>>>
>>> A quick glance at the code would suggest that in the
>>> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager on=
e
>>> could replace line 708 from
>>>
>>> CacheObject oldVal =3D recordable ? entry.rawGet() : null;
>>>
>>> to
>>>
>>> CacheObject oldVal =3D recordable ? entry.rawGetOrUnmarshal(false) : nu=
ll;
>>>
>>> to get the values attached to the events. Would that work?
>>>
>>> Thanks,
>>>
>>> Abraham
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-ignite-users.70518.x6.nabble.com/Eviction-Events-with-off=
heap-values-tp4853.html
>>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>


--=20

Best regards,
Alexei Scherbakov

--001a11353aaa3400760532ff0e8f--