This article documents how to work with your cache in Liferay DXP 7.0, in order to modify its size, time to live (TTL) and replication.
Resolution
Modify Default Cache Sizes and Entry TTLs
A potential source of confusion is the ehcache.multi.vm.config.location portal property. This property was used in earlier Liferay platform releases to modify the Liferay platform's default cache sizes and/or behavior, or when modifying specific cache size and/or behavior in releases that pre-dated LPS-17296 when the Liferay platform added the ability to modify individual cache settings using the platform's hook plugins.
This portal property still works with Liferay DXP, but you are no longer allowed to specify absolute paths as you could in past releases. Rather, the source code for EhcachePortalCacheManager indicates that it only accepts classpath relative values only. This means that the file that is specified in this portal property must either exist as a bundle fragment for the com.liferay.portal.cache.ehcache bundle, or it must exist in WEB-INF/classes for the Liferay application.
Modify Specific Cache Sizes and Entry TTLs
In line with the cache configuration hook mechanism that was added in 6.2, Liferay usually expects you to only add new caches or modify existing caches rather than completely replace the cache configuration file. You can customize the size of a Liferay cache and the default amount of time a cache entry will live by creating an OSGi component that provides the PortalCacheConfiguratorSettings service.
Unlike many Liferay services, this is actually a base class rather than an interface, where the only constructor that's available accepts two arguments: the classloader that can be used to load some resource file, and the path to that resource file. This resource file can be named whatever you wish, as long as it can be found in the classloader you pass to the constructor for PortalCacheConfiguratorSettings. The file itself only contains cache entries that should look exactly like the ones inside of the portal-cache-ehcache module.
Existing implementations in Liferay (DDMRESTDataProviderCacheConfiguratorSettings, JournalMultiVMClusteredCacheConfiguratorSettings) also add a dependency on a lifecycle event (specifically, PORTAL_INITIALIZED) so that the configuration doesn't start too early.
Modify Cache Replication
MultiVMEhcachePortalCacheManagerConfigurator determines how cache replication should happen based on values set in portal properties. If you are using a version of Liferay before DE-28, it's also important to note that, as described in LPS-73830, the cache must be declared in the default configuration file, specified in ehcache.multi.vm.config.location, in order for the portal properties changes to take effect.
Before DE-26, the property name you needed to set was ehcache.cluster.link.replicator.properties:
ehcache.cluster.link.replicator.properties.TEST_CACHE=replicatePutsViaCopy=true,replicateUpdatesViaCopy=true
With DE-26, Liferay began preparing changes that would allow clustering to be available to CE, but Liferay opted to leave its cluster-linked based replication mechanism for EE customers only. In order to avoid potential confusion, the property name was changed to ehcache.replicator.properties with DE-26 and subsequently made available to CE users with 7.0.4 GA5:
ehcache.replicator.properties.TEST_CACHE=replicatePutsViaCopy=true,replicateUpdatesViaCopy=true
To avoid confusion, we'll refer to these as ehcache.replicator.properties, and you can change the prefix from ehcache to ehcache.cluster.link if you are using DE-25 or earlier.
At an implementation level, the Liferay platform checks the ehcache.replicator.properties.default property and merges any cache-specific properties specified in ehcache.replicator.properties.${cache.name} for each cache.
Therefore, to implement any changes to how a cache should handle replication, you should update portal-ext.properties to set either ehcache.replicator.properties.default (if you wish to change the defaults) or ehcache.replicator.properties.${cache.name} (if you wish to change just one cache's behavior). If a value is not specified in either property, it falls back to constants specified in PortalCacheReplicator.
If in your code, you wish to specifically prevent all replication for a put or remove event, you can use the corresponding methods in PortalCacheHelperUtil. Note that an update would simply use the method for putting an entry into the cache.