Databases Reference
In-Depth Information
As shown in the preceding diagram, we have four Liferay Portal nodes in the cluster.
Each node is connected with each other. So in total, it will create around twelve RMI
links to replicate the cache across other nodes. This option uses a thread-per-cache
replication algorithm. Hence, it creates a massive number of threads for replicating
the cache over the cluster. Because of this algorithm, this option adds a lot of
overhead and affects the overall performance of the system.
Ehcache replication using Cluster Link
This option is available for the enterprise version of Liferay Portal. In this approach,
Liferay Portal creates a limited number of dispatcher threads that are responsible for
replicate cache over the cluster. As in this approach all requests pass through a single
place before they are actually distributed in the network, it gives a chance to remove
unnecessary requests. For example, if the same cache object is changed by multiple
nodes, instead of sending two requests to all the nodes to invalidate cache, only one
request will be sent. This feature reduces network traffic. The following architectural
diagram explains this feature in detail:
Liferay Portal
Server 1
Liferay Portal
Server 2
Cluster Link
Liferay Portal
Server 3
Liferay Portal
Server 4
As shown in the preceding diagram, all four Liferay Portal nodes are connected to
each other using Cluster Link. Internally, this feature uses UDP multicast to establish
a connection with cluster nodes. A small group of threads is created to distribute
cache update events to all the connected nodes. It is recommended to use this option
for Ehcache replication.
