On Thu, Mar 15, 2018 at 12:31 PM, Denis Magda wrote:
> >
> > Agree with AG. There is a difference between expiration and eviction. If
> an
> > entry is expired, then it should be removed from the store, regardless if
> > it is in memory or on disk.
>
>
> Well, then it works this way now depending
>
> Agree with AG. There is a difference between expiration and eviction. If an
> entry is expired, then it should be removed from the store, regardless if
> it is in memory or on disk.
Well, then it works this way now depending on a memory configuration:
- memory only mode: expired entry rem
On Wed, Mar 14, 2018 at 1:41 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Denis,
>
> With the approach of Ignite Durable Memory there is no difference between
> 'memory' and 'disk'. The data is expired from the Ignite data storage which
> can be persisted or not. Before persistence
Denis,
With the approach of Ignite Durable Memory there is no difference between
'memory' and 'disk'. The data is expired from the Ignite data storage which
can be persisted or not. Before persistence was introduced, TTL was mostly
used when write-through was enabled, otherwise data was cleared fr
Alexey,
My understanding was that the expiration policies worked for data in RAM
only. Ok, if an expired entry is removed from both RAM and Ignite
persistence then what happens if a cache store is used instead of Ignite
storage? Do we remove expired entries from RDBMs, Cassandra, etc? My guess
tha
Dmitriy,
The TTL map is a regular B+Tree-based map with the key being a pair (expire
time + key). It is obviously stored in memory when there is no persistence.
When persistence is enabled, it is handled as any other index tree - the
page replacement algorithm is applied. No heap is consumed for t
On Tue, Mar 13, 2018 at 3:50 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Denis,
>
> What do you mean by 'current behavior when data is evicted from the memory
> only'? TTL expiration effectively means that the corresponding key-value
> pairs are destroyed.
AG, can you please expl
Hi Denis,
I've created summary of terms here
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-Eviction,rotationandexpiration
Hope this should solve a lot of miscommunications.
In this thread I meant only Expiration (aka TT
Denis,
What do you mean by 'current behavior when data is evicted from the memory
only'? TTL expiration effectively means that the corresponding key-value
pairs are destroyed. If you are talking about page replacement, then there
is no way to do this on per-key basis because a page must be replace
To be honest, I am not clear how this would be implemented. Currently, we
keep TTL map in memory and it fits in memory. However, if we start tracking
entries on disk, the TTL map will grow too large and may not fit in memory
any longer.
Can someone explain how this will be handled?
D.
On Mon, Ma
Dmitriy,
It will break the current default behavior when data is evicted from the
memory only, and I would disagree that it's a right decision overall.
There are many scenarios when users need to have the eviction in the memory
layer and preserve data on disk for later usage. So, can we keep what
Denis,
I suppose there is no configuration will be required. If TTL configured
entry will be removed from disk & memory both.
SIncerely,
Dmitriy Pavlov
пн, 12 мар. 2018 г. в 23:32, Denis Magda :
> Alexey, Dmitriy,
>
> What would be the configuration parameter that defines if the eviction
> shou
Alexey, Dmitriy,
What would be the configuration parameter that defines if the eviction
should happen in the in-memory layer only or in both memory and disk?
--
Denis
On Mon, Mar 12, 2018 at 9:22 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Val,
>
> Yes, the entries will be remov
Val,
Yes, the entries will be removed from both memory and persistence.
2018-03-12 19:20 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:
> Alex,
>
> What is behavior going to be after IGNITE-5874 is fixed? Will expired entry
> be removed from both memory and persistence?
>
> -Val
Alex,
What is behavior going to be after IGNITE-5874 is fixed? Will expired entry
be removed from both memory and persistence?
-Val
On Sat, Mar 10, 2018 at 12:06 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> The ticket [1] is in patch available state looks good, the only thing lef
Hi Denis,
yes, this is about PDS + entry expiration (TTL).
Please note there is second issue, than is visible by user
https://issues.apache.org/jira/browse/IGNITE-6964
'transfer of old entries to new storage' means DB entries migration from
old format to new. We defenetely should have PDS compat
Alex,
Is that ticket about the eviction from the persistence layer? It's not
obvious from the description.
Also, what do you mean by the "transfer of old entries to new storage" (how
is it intended to work and what's a rationale if you're talking about pages
movement from Ignite persistence to an
The ticket [1] is in patch available state looks good, the only thing left
there is to transfer old entries to new storage. I hope Andrey will have
time to finish this soon, so we can target the fix for 2.5.
[1] https://issues.apache.org/jira/browse/IGNITE-5874
2018-03-09 22:51 GMT+03:00 Denis Ma
Val,
I'd like to hear Alexey G. opinion on this? Alex, please chime in.
In general, the more deployments the persistence will get the more demand
we will see for that capability. Personally, I'd create a ticket for now
and put it off to our backlog.
--
Denis
On Fri, Mar 9, 2018 at 9:34 AM, Dmi
On Fri, Mar 9, 2018 at 3:43 AM, Dmitry Pavlov wrote:
> As far as I know there is no plans. Denis please correct me if I'm wrong.
>
> But users found these or similar bugs, it seems we need to support PDS and
> TTL.
>
We should either support it or throw a clear exception on startup clearly
stat
As far as I know there is no plans. Denis please correct me if I'm wrong.
But users found these or similar bugs, it seems we need to support PDS and
TTL.
пт, 9 мар. 2018 г., 4:36 Valentin Kulichenko :
> Guys,
>
> What is the result of this discussion? Do we still not support eviction and
> expir
Guys,
What is the result of this discussion? Do we still not support eviction and
expiration on persistence level? If so, any plans to change this?
-Val
On Tue, Nov 21, 2017 at 9:45 AM, Denis Magda wrote:
> We might break the compatibility for the next major release or even create
> a tool tha
We might break the compatibility for the next major release or even create a
tool that will migrate persistence files from an old to new formats.
—
Denis
> On Nov 21, 2017, at 8:34 AM, Dmitry Pavlov wrote:
>
> Hi Denis,
>
> Second fix we need to do is B+ tree separation in per-partition basis
Hi Denis,
Second fix we need to do is B+ tree separation in per-partition basis:
https://issues.apache.org/jira/browse/IGNITE-5874
Should we take into account compatibilty issues with previous Ignite
persistent store versions, because current TTL tree is persisted, and will
change its format?
Si
Dmitriy,
That’s about TTL and eviction support for Ignite persistence. Presently if you
set an expiration or eviction policy for a cache it will be applied for data
stored in memory. The policy never affects the persistence layer.
—
Denis
> On Nov 20, 2017, at 9:29 AM, Dmitry Pavlov wrote:
>
Hi Denis,
Is this need covered by PDS + TTL?
For the very first TTL test, I found some delay after applying TTL with the
repository enabled: https://issues.apache.org/jira/browse/IGNITE-6964
And I'm wondering if the user's needs are covered by
https://apacheignite.readme.io/docs/expiry-policies
Hi Denis,
What is the difference of required by users functionality with TTL cache
expiration?
By some posts I can suppose TTL cache is compatible with native
persistence.
Sincerely,
Dmitriy Pavlov
сб, 18 нояб. 2017 г. в 0:41, Denis Magda :
> Igniters,
>
> I’ve been talking to many Ignite user
Igniters,
I’ve been talking to many Ignite users here and there who are already on Ignite
persistence or consider to turn it on. The majority of them are more than
satisfied with its current state and provided capabilities. That’s is really
good news for us.
However, I tend to come across the
28 matches
Mail list logo
