Ambiguity regarding ttl and gc_interval relation.

[benonymus]

Hey,

I find the ttl and gc_interval a bit confusing.

Is ttl always required?
What happens if it is not set?
What if it is longer than the gc_interval?

Thank you

[cabol]

Hey!

I understand it may be confusing, but this is actually explained in the Eviction configuration section – Nebulex.Adapters.Local. Perhaps the docs can be improved, but I think it should help to understand.

Is ttl always required?

No, it is not, this is an option that is optional.

What happens if it is not set?

The :ttl option is supposed to be a global or shared option across the adapters, therefore, it will depend on the adapter also. However, for the Nebulex.Adapters.Local adapter which is the one I suppose you're interested in. Let me first explain what happens when the option :ttl is set. When :ttl is set, every time the key is accessed, the local adapter checks the TTL, and if it has expired, it removed the key from the cache at that moment, which means, it is evaluated on-demand every time the key is accessed or fetched. So, when it is not set, the adapter doesn't check the TTL for that key. Also, when it is not set, for the eviction you basically depend completely on the generation manager, which runs every X period of time given by :gc_interval option. When :gc_interval occurs, a new generation is created, evicting the keys in the older one (releasing memory space). Since it is a generation cache, this process ensures the evicted keys are the least frequently used.

What if it is longer than the gc_interval?

I think this is explained in the link I shared above, there is a section about the :ttl option. But to give a quick answer, when the :ttl is longer than the :gc_interval, there may be a situation where the GC runs removing the older generation and a key previously set with a TTL is removed, even it the TTL hasn't happened yet. Overall, the :gc_interval has precedence over the :ttl (you can find more info in the link I shared).

Let me know if this addresses your inquiries, I stay tuned. Thanks!

[benonymus]

Hey,

Thanks a lot!

I am using the partitioned adapter.

So if I understand correctly, if I don't set a ttl and :gc_interval passes only items that have not been accessed in the period are removed? Or in the last 2 period (generation)?
If an item is accessed they are kept around forever?
But if they have ttl they are removed when accessed next time and the ttl is over?

[cabol]

So if I understand correctly, if I don't set a ttl and :gc_interval passes only items that have not been accessed in the period are removed? Or in the last 2 period (generation)?

In the 2nd period (after 2 generations are pushed). To give an example, suppose your cache start, then there will be just one generation, and items start getting accessed. Then :gc_interval runs and a new generation is created, at this time you have 2 generations, the new one starting empty and the older one. Then in the next :gc_interval cycle, a new generation is created and is set as the new one, the previously new one goes to be the older one, and the previously older one is deleted. The next cycle is the same. As you said, an item stored in the newest generation will be evicted after 2 cycles (two GC runs), the first one goes to the older generation, and the next one is removed. So, when an item or key is continuously hit, it will be kept in the newest generation all the time, well, as long as it keeps being hit.

If an item is accessed they are kept around forever?

Sort of, if the item or key is continuously hit, which is, it is accessed at least once before the 2nd cycle runs, the key will be always around.

But if they have ttl they are removed when accessed next time and the ttl is over?

That is correct!

[benonymus]

Thanks for the clarification!