Ask Questions and Find Answers

Joaquin CabalHi,  we are working with liferay 7.0 DXP  and have some doubts aboute the clustering config.

This is current config:

cluster.link.enabled=true
lucene.replicate.write=true
org.quartz.jobStore.isClustered=true
ehcache.cluster.link.replication.enabled=true

We have same Repository in both nodes, with AdvancedFileSystem. 
Also same Database.
We have an own osgi module running on each node with some logic that doesn't use Ehcache and has custom cache for Journal articles.

Starting from the end: You have a custom cache for Journal articles, and are wondering why it's not updated through Liferay's cluster communication? Start there. Or eliminate the cache - at least for a quick test.

You should see evidence of proper caching (and peer discovery) in the logs. The default configuration uses Multicast. If that's disabled, or if the machines can't see each other, the cluster won't be formed properly. Sooner or later you'll see each other's articles, but that's only when the cache has been flushed.

You also didn't mention that you've configured all nodes to contact the same Elasticsearch instance.

Joaquin Cabal

At osgi module level, a simple singleton class , when the variables of one node change , the other node should change also? Or the sinc of nodes is not at that level.

No, there's no magic of reaching into another process's memory. When an object is modified, the cluster communication layer will communicate the id of the changed object to the other cluster machines. In turn, the other nodes will remove the object in question from the cache.

This means that any future access to those objects won't be served from cache, so that they'll be accessed from database, thus be current again.

If you keep any objects in your own variables, there's nothing that the cluster communication can do. In fact, keeping objects over long time in singletons is a recipe for disaster: You might even keep references to code that has long been undeployed. Don't do that. This is the "custom cache" that you should eliminate. In fact, it's arguable that "cache" is a good name for this. Keep the id and access the objects through the API when you need them. If they're in cache, they'll be served quickly. If they're not in cache, they'll be served with the current and updated fresh data.