Dear Docs team,
While working on a clustering related ticket, we came across the following article which contains incorrect article that lead the customer astray.
The article and section in question: Liferay portal clusering
Excerpt (emphasis added by me):
The cache is distributed across multiple Liferay Portal nodes running concurrently. Enabling Cluster Link can increase performance dramatically. For example, if two users are browsing the message boards, and the first user clicks a thread, Liferay Portal must grab that thread from the database, cache it, and format it for display in the browser. When Cluster Link is enabled, the cache is replicated to the other nodes in the cluster. If another user wants to read that thread, it's retrieved from the cache, no matter what node serves that user, because the cache is replicated. Because the thread is in the cache, no trip to the database is necessary.
This is not true by default. Liferay's default configuration comes from the PortalCacheReplicator interface, which is used to configure ehcache unless it's overwritten with custom values. The two important ones for this section are:
Checking the Ehcache javadocs, we find the following:
replicatePuts: Whether to replicate puts.
replicatePutsViaCopy: Whether a put should replicated by copy or by invalidation, (a remove)
Since replicatePutsViaCopy is set to false, the cache will not be replicated to the other nodes, only a "remove" message will be sent. This means that by default, a trip to the database is required to populate the cache on the other node.