CODEWITHSUNDEEP
javahazelcasthazelcast-imap
Indraneel Bende
Indraneel Bende

Reputation: 3486

Hazelcast - Evicting an entry from a IMap after a fixed period of time, no matter how many times it is updated

I have the following use case where I need an entry to be evicted from an IMap, no matter how many times it is Updated. My key is a String and my value is a Java Object.

If for example, an entry is added on 12th May, it needs to be evicted after 14 days, i.e. 26th May, no matter how many times it is updated.

Hazelcast has a tag in its configuration called time-to-live-seconds, where you can configure how much time an entry can stay in a map.

So from Hazelcast Documentation,

"Maximum time in seconds for each entry to stay on the map. If it is not 0, entries that are older than this time and not updated for this time are evicted automatically. Valid values are integers between 0 and Integer.MAX VALUE. Its default value is 0, which means infinite. If it is not 0, entries are evicted regardless of the set eviction-policy."

So, with the above, if you consider the above example, an entry added originally on 12th May and then updated on 24th May will be removed 14 days after the 24th of May, not on 26th May.

Hence, to solve the above problem, I am using the following approach. When I have to update an entry, I am first getting the EntryView from the Map and then using that obtaining the Expiration Time. Then getting the current time and taking the difference of expiration time with the current time and then updating the value, with time-to-live as the difference of expiration time and the current time.

    Employee employee= IMap.get("A12");
    employee.setDescr("loasfdeff");
    EntryView<String,Employee> entryView=iMap.getEntryView("A12");
    Long expirationTime=entryView.getExpirationTime();
    Long currentTime=System.currentTimeMillis();
    Long difference=expirationTime-currentTime;      
    iMap.set("A12",employee, difference, TimeUnit.MILLISECONDS);

I have tested the above approach, and it works. Although, I would like to explore other alternatives to see if there is anything hazelcast provides out of the box, to help me solve my use-case.

Any help is much appreciated!

EDIT-

GITHUB ISSUE- https://github.com/hazelcast/hazelcast/issues/13012

Upvotes: 0

Views: 1643

Answers (1)

Scott M
Scott M

Reputation: 84

You are correct in how the TTL operates. A simple update of an entry is essentially the same as putting a new entry, so the system can’t interpret the intention. However, this would be a nice enhancement: adding a switch to preserve the expiration datetime.

I have a couple of alternative approaches:

1) Consider adding a timestamp field to the value object and setting this to the current time on the original object put. Once that’s present you could write an executor service to run at intervals and invalidate the objects based on the overall TTL you want. You can index this field as well to make it more performant.

2) You can write a custom eviction policy by extending the MapCustomEvictionPolicy class and applying that to your map. You would most likely still need to add a timestamp in the value (or key if you wanted to make that a custom object). You would then have a blank slate for how you want this to work.

I’ll create a product enhancement request for this in the meantime. Could probably get it in the next release as it doesn’t seem too hard of an add.

Upvotes: 1

Related Questions