After spending several days reading countless blog posts, forum topics, and, of course, SO questions, I would like to summarize here how we finally managed to configure cache replication in the Liferay 6.2 cluster using unicast TCP for Amazon EC2.
JGroups configuration
Before you configure Liferay to cache replication, you should understand that Liferay relies on JGroups pipes. Basically, JGroups allow you to discover and communicate with remote instances. By default (at least in Liferay), it uses multicast UDP to achieve these goals. See the JGroups website for more details .
To enable unicast TCP, you must first get the JGroups TCP configuration file from jgroups.jar in the Liferay webapp (something like $LIFERAY_HOME/tomcat-7.0.42/webapps/ROOT/WEB-INF/lib/jgroups.jar ). Extract this file to a location accessible by the Liferay class webapps classpath. Say $LIFERAY_HOME/tomcat-7.0.42/webapps/ROOT/WEB-INF/classes/custom_jgroups/tcp.xml . Pay attention to this way.
For this configuration to work in a Liferay cluster, you just need to add the singleton_name="liferay" attribute to the TCP tag:
<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.1.xsd"> <TCP singleton_name="liferay" bind_port="7800" loopback="false" ...
You may have noticed that:
but. this configuration file does not indicate the binding address for listening, but
C. that the original cluster hosts must be installed through the system property.
In fact, you need to change $LIFERAY_HOME/tomcat-7.0.42/bin/setenv.sh to add the following JVM system properties:
-Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=192.168.0.1 -Djgroups.tcpping.initial_hosts=192.168.0.1[7800],80.200.230.2[7800]
The bind address determines which network interface to listen on (the JGroups port is set to 7800 in the TCP configuration file). The property of the initial hosts must contain each individual instance of the cluster (for more details, see TCPPING and MERGE2 in the JGroups docs ) together with its ports for listening. Remote instances can refer to their hostnames, local addresses, or public addresses.
( Tip: if you are setting up a Liferay cluster on Amazon EC2, most likely the local IP address and host name of your instances are different after each reboot. To get around this, you can replace the local address in setenv.sh with the result of the hostname: `hostname` command - pay attention to backlinks)
( Tip: if you use security groups in EC2, you must also open port 7800 for all instances in the same security group)
Liferay Configuration
JGroups replication is included in Liferay by adding the following properties to your portal -ext.properties:
# Tells Liferay to enable Cluster Link. This sets up JGroups control and transport channels (necessary for indexes and cache replication) cluster.link.enabled=true
Setting up JGroups for unicast TCP is just an indication of the correct file:
# Configures JGroups control channel for unicast TCP cluster.link.channel.properties.control=/custom_jgroups/tcp.xml
In the same file, Lucene index replication requires this single property:
# Enable Lucene indexes replication through Cluster Link lucene.replicate.write=true
EhCache cache replication is more subtle. You must configure JGroups for both the Hibernate cache and the Liferays internal caches. To understand this configuration, you should know that with Liferay 6.2 , the default configuration files for EhCache are “clustered” ( do not set these properties ):
# Default hibernate cache configuration file net.sf.ehcache.configurationResourceName=/ehcache/hibernate-clustered.xml
These configuration files rely on EhCache plants that must be configured to enable JGroups:
JGroups factory peer caching provider expects a file parameter containing JGroups configuration. Specify the TCP unicast configuration file:
# Configure hibernate cache replication for unicast TCP net.sf.ehcache.configurationResourceName.peerProviderProperties=file=/custom_jgroups/tcp.xml
( Tip: if in doubt, you should refer to the property definitions and default values: https://docs.liferay.com/portal/6.2/propertiesdoc/portal.properties.html )
Debugging
Alternatively, you can enable debug tracing with:
cluster.executor.debug.enabled=true
You can even say that Liferay displays on all pages the name of the node that processed the request:
web.server.display.node=true
Finally, JGroups channels provide a diagnostic service available through a search tool .
Final note
Please keep in mind that this applies only to indexes and cache replication. When configuring a Liferay cluster, you should also consider configuring:
- Shared Database (RDS on AWS),
- General DocumentLibrary (S3 or RDS on AWS),
- Session replication on Tomcat,
- And maybe more depends on how you use Liferay.