hibernatecachinginfinispan

Why is Infinispan expiration reaper needed in clustered cache modes

We use infinispan as our second Level Cache in hibernate. This is our cache config for most of our entities:

<invalidation-cache-configuration
   name="entity"
   mode="ASYNC">
 <encoding media-type="application/x-java-object"/>
 <locking concurrency-level="1000" acquire-timeout="1000"/>
 <transaction mode="NONE"/>
 <expiration max-idle="-1" interval="0" lifespan="-1" />
 <memory max-count="2000000"/>
</invalidation-cache-configuration>

It gives lots of warnings:

ISPN000025: wakeUpInterval is <= 0, not starting expired purge thread

In the docs it says:

If you use clustered cache modes, you should never disable the expiration reaper.

Additional the docs are saying there is a "touch" command which syncs "recently accessed" metadata in the cluster.

This might degrade performance as "cache.get() requests do not return until all touch commands complete". Next paragraph the doc says: "Maximum idle expiration does not work with invalidation mode." So I am confused.

I am wondering:

  1. Why do we need a reaper thread running every minute if the objects should never expire? Can I disable it with interval="0"?

  2. Why do we need a touch command? Can I disable it? Should I set at least touch mode to "ASYNC"?

Solution

  • It gives lots of warnings:

    ISPN000025: wakeUpInterval is <= 0, not starting expired purge thread

    It is an INFO level message which is lower than WARN. The reason you see lots is because it is printing the message once per cache that is configured like this. If you want you can leave your configuration as is and just ignore the INFO messages, they are one time things at startup.

    1. Why do we need a reaper thread running every minute if the objects should never expire? Can I disable it with interval="0"?

    Yes, you can. Note that from the Infinispan perspective we cannot tell if an object may never expire since we also allow a programmatic override to write operations that can supply expiration at runtime. The INFO message is just to tell the user "hey we won't pick up expired entries automatically, on access only"

    1. Why do we need a touch command? Can I disable it? Should I set at least touch mode to "ASYNC"?

    I think you may have been combining sections. The touch command is only used when using max-idle expiration, lifespan expiration does not use touch commands. The touch command is not used with your use case with no expiration.

    The touch command is required with max idle due to when a read is done on one node the other owners will not know that was done, so we have to send those touch commands to tell the other owner node(s), so they don't think the entry is actually expired.

    Next paragraph the doc says: "Maximum idle expiration does not work with invalidation mode."

    Clustered Max idle does not work with invalidation caches since it defeats the main benefits of invalidation. Normally the application updates the DB and invalidates the cache in the same transaction, so max idle is not normally needed. Clustered max idle would have to send a touch command to all nodes in the cluster on every read, adding that overhead.

    Non clustered max idle could work with invalidation caches, but this has not requested afaik. You can create a New Feature at https://issues.redhat.com/browse/ISPN if you wanted as well.