hazelcast "time-to-live-seconds" and "max-idle-seconds" config not working

[ji...@xthplanet.com]

Hi~

I am trying to use AsyncMap as cache. 

and I have set cluster.xml of hazelcast as below.

But, "time-to-live-seconds" and "max-idle-seconds"  are not working as expected.

AsyncMap datas are not evicted.

Do I need to add any code to use this function?

map configuartion in cluster.xml 

-------------------------------------------------------------------------------------------

<map name="__vertx.haInfo">

    <!--

        Number of backups. If 1 is set as the backup-count for example,

        then all entries of the map will be copied to another JVM for

        fail-safety. 0 means no backup.

    -->

    <backup-count>0</backup-count>

    <async-backup-count>1</async-backup-count>

    <!--

  Maximum number of seconds for each entry to stay in the map. Entries that are

  older than <time-to-live-seconds> and not updated for <time-to-live-seconds>

  will get automatically evicted from the map.

  Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.

-->

    <time-to-live-seconds>0</time-to-live-seconds>

    <!--

  Maximum number of seconds for each entry to stay idle in the map. Entries that are

  idle(not touched) for more than <max-idle-seconds> will get

  automatically evicted from the map. Entry is touched if get, put or containsKey is called.

  Any integer between 0 and Integer.MAX_VALUE. 0 means infinite. Default is 0.

-->

    <max-idle-seconds>10</max-idle-seconds>

    <!--

        Valid values are:

        NONE (no eviction),

        LRU (Least Recently Used),

        LFU (Least Frequently Used).

        NONE is the default.

    -->

    <eviction-policy>NONE</eviction-policy>

    <!--

        Maximum size of the map. When max size is reached,

        map is evicted based on the policy defined.

        Any integer between 0 and Integer.MAX_VALUE. 0 means

        Integer.MAX_VALUE. Default is 0.

    -->

    <max-size policy="PER_NODE">0</max-size>

    <!--

        When max. size is reached, specified percentage of

        the map will be evicted. Any integer between 0 and 100.

        If 25 is set for example, 25% of the entries will

        get evicted.

    -->

    <eviction-percentage>25</eviction-percentage>

    <!--

        While recovering from split-brain (network partitioning),

        map entries in the small cluster will merge into the bigger cluster

        based on the policy set here. When an entry merge into the

        cluster, there might an existing entry with the same key already.

        Values of these entries might be different for that same key.

        Which value should be set for the key? Conflict is resolved by

        the policy set here. Default policy is PutIfAbsentMapMergePolicy

        There are built-in merge policies such as

        com.hazelcast.map.merge.PassThroughMergePolicy; entry will be added if there is no existing entry for the key.

        com.hazelcast.map.merge.PutIfAbsentMapMergePolicy ; entry will be added if the merging entry doesn't exist in the cluster.

        com.hazelcast.map.merge.HigherHitsMapMergePolicy ; entry with the higher hits wins.

        com.hazelcast.map.merge.LatestUpdateMapMergePolicy ; entry with the latest update wins.

    -->

    <merge-policy>com.hazelcast.map.merge.LatestUpdateMapMergePolicy</merge-policy>

  </map>

[MUNGAI NJOROGE]

Hello, From my understanding, you should set

-->
<max-size policy="PER_NODE">0</max-size>
<!--

To have a value of >0 and set eviction-policy to LRU or LFU.

[ji...@xthplanet.com]

Thanks for you reply Mungai.

I think eviction-policy config is for memory overflow issue.

and on my understanding, regardless of the eviction-policy, "max-idle-seconds" config should work.

2018년 9월 20일 목요일 오후 2시 36분 14초 UTC+9, MUNGAI NJOROGE 님의 말:

[MUNGAI NJOROGE]

The eviction policy and the memory control whether an eviction should be performed. The cache is cleared once the memory limit is reached or when new items need to be added to the cache that might cause memory limit to be exceeded.

Check on map eviction policy from Hazelcast documentation.

Regards.

[ji...@xthplanet.com]

Thanks again Mungai.

I will check again hazelcast documentation.

Regards

2018년 9월 20일 목요일 오후 5시 15분 10초 UTC+9, MUNGAI NJOROGE 님의 말:

[MUNGAI NJOROGE]

Welcome,

This might help: https://docs.hazelcast.org/docs/3.3-RC3/manual/html/map-eviction.html

[ji...@xthplanet.com]

Thanks for your link.

Following th link :https://docs.hazelcast.org/docs/3.3-RC3/manual/html/map-eviction.html

----

eviction-policy: Valid values are described below.

• NONE: Default policy. If set, no items will be evicted and the property max-size will be ignored. Of course, you still can combine it with time-to-live-seconds and max-idle-seconds.

---

I think, regardless of "eviction-policy" , we can use time-to-live-seconds and max-idle-seconds.




Am i missing some other thing? or any idea ?

2018년 9월 20일 목요일 오후 5시 21분 58초 UTC+9, MUNGAI NJOROGE 님의 말:

[ji...@xthplanet.com]

Any update of this issue? 

2018년 9월 20일 목요일 오후 10시 6분 38초 UTC+9, ji...@xthplanet.com 님의 말:

[Thomas SEGISMONT]

As replied on Github where you cross posted this question, it seems you are modifying the "haInfo" map configuration. This is a Vert.x internal map for clustering administration and you shouldn't change its settins.

If you want to configure a particular HZ map, create another map xml block, having the name of your Vert.x AsyncMap. Then configure ttl ... etc

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/aa5496b9-965c-4cf3-bf4c-a25b290c21c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ji...@xthplanet.com]

Thanks Thomas,

It looks I was misunderstanding how to use hz map.

I will try what you told.

Regards.

2018년 9월 28일 금요일 오후 5시 51분 27초 UTC+9, Thomas Segismont 님의 말: