Ehcache configuration changes

Starting in 6.1 there will be a change in how caches are configured for the portal and plugins. This new mechanism only applies for ehcache caches.

Changes to default cache configuration:

Configuring caches for clustering is simpler. Instead of having to switch config files in portal.properties, the default Liferay cache configurations will be loaded and automatically configured. The portal will configure ehcache for not clustered, clustered using RMI, and clustered using Cluster Link. Before the difference between liferay-multi-vm.xml and liferay-multi-vm-clustered.xml was the presence of RMI cache listeners designed to replicate the cache across a cluster. This adds unnecessary overhead for a non-clustered deployment, hence the different configuration files. Now the portal will automatically remove the relevant listeners if the portal is not in a clustered configuration. Configurations regarding enabling and using Cluster Link replication remains the same.

These changes do not prevent you from defining a custom cache configuration file. If you decide to configure your own instead of using the default Liferay one, simply direct the ehcache.multi.vm.config.location property to go to your configuration file. Ensure that your custom file is located on a different path or a different file name as the portal may confuse it with the default configuration file. The portal will not alter a custom configuration. This means that if you decide to use a custom configuration you will have to decide on and configure your clustering settings in the configuration file as before. The same logic applies for hibernate cache configurations. The change has no impact on single-vm caches as they are not replicated across a cluster.

New plugin-based cache configuration:

You can now dynamically change any cache configuration during runtime via plugins. Before the only way to change a cache configuration at runtime was via the cache MBeans, but this configuration was transient and was restricted to the properties that ehcache allowed you to change after a cache is initialized. This mechanism was also restricted to only the single and multi vm caches as Hibernate caches were not exposed.


Plugin cache reconfiguration allows:

  1. Reconfigure any cache (Single VM, Multi VM, and Hibernate)
  2. Creating new caches, including caches for ServiceBuilder services introduced in a plugin
  3. This capability can be leveraged in any plugin.

To use in a plugin you simply need to add a portlet.properties file to your plugin that defines the same properties that are used in the core portal to define cache configuration file location:

  • net.sf.ehcache.configurationResourceName
  • ehcache.single.vm.config.location
  • ehcache.multi.vm.config.location

The location defined in the above properties for a plugin is defined relative to the plugin's context.

Other notes:

Ehcache does not allow changes to most settings in a cache once the cache has started storing objects. As a result, reconfiguring a cache will result in cached objects being flushed.

It is recommended that cache overriding be carefully managed as plugin loading order is not gauranteed. The final plugin to be loaded will determine the cache configuration.

Blogs
Thanks for the update. One question though. Is Cluster Link deployed or bundled with the portal by default?
Cluster Link is part of the core portal and must be enabled when deploying a cluster for non-cache related communication between the nodes. It is configured using the cluster.link.* properties in portal.properties.

Cluster Link-based replication is off by default as it is only available in EE. For more info on it see Shuyang's blog post: http://www.liferay.com/about-us/news/-/blogs/5229206/maximized
Thanks for the update Ed!
Hi, Edward,

I want to tell you what I like about Liferay portal:

"If you decide to configure your own instead of using the default Liferay one, simply direct the ehcache.multi.vm.config.location property to go to your configuration file."
Hi Edward,

I am trying to test ehcache clustering in Liferay 6.1 CE built from trunk. I have a quick question. If I have two Liferay CEs running in the same LAN, will the ehcache be clustered by default? Is there autodiscovery among such instances? Or do I have to set any particular property or properties to enable ehcache clustering.

Thanks
Hi Edward,

Please ignore my last question. I found the wiki article http://www.liferay.com/community/wiki/-/wiki/1071674/JBoss-Tomcat-Liferay+portal+Clustering+-+what+and+how/maximized useful.

Thanks
Hi, Edward,

I have configured a cluster of two Liferay portal 6.0 SP1 JBoss 5.1.0 nodes to use TCP unicast for cache replication and session replication. It works with Liferay portal in its out-of-the-box state. However, when I deploy a custom portlet with service builder code, it throws the following exceptions:

2011-10-30 22:21:07,579 INFO [STDOUT] (main) Loading vfsfile:/appshr/liferay/testliferay/liferay-portal-6.0-ee-sp1/jboss-5.1.0/server/testlrayServer1/deploy/search-portlet.war/WEB-INF/classes/service.properties
2011-10-30 22:21:08,176 ERROR [net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProvider]
(main) Failed to create JGroups Channel, replication will not function. JGroups properties:
null
org.jgroups.ChannelException: unable to setup the protocol stack
at org.jgroups.JChannel.init(JChannel.java:1728)
at org.jgroups.JChannel.<init>(JChannel.java:249)
at org.jgroups.JChannel.<init>(JChannel.java:232)
at org.jgroups.JChannel.<init>(JChannel.java:173)
at net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProvider.init(JGroupsCacheManagerPeerProvider.java:131)
at net.sf.ehcache.CacheManager.init(CacheManager.java:363)
at net.sf.ehcache.CacheManager.<init>(CacheManager.java:228)
at net.sf.ehcache.hibernate.EhCacheProvider.start(EhCacheProvider.java:99)
at com.liferay.portal.dao.orm.hibernate.CacheProviderWrapper.start(CacheProviderWrapper.java:62)
at com.liferay.portal.dao.orm.hibernate.EhCacheProvider.start(EhCacheProvider.java:67)
at org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge.start(RegionFactoryCacheProviderBridge.java:72)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:236)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1842)
at org.springframework.orm.hibernate3.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:860)
... ...

at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassCastException: org.jgroups.protocols.UDP cannot be cast to org.jgroups.stack.Protocol
at org.jgroups.stack.Configurator.createLayer(Configurator.java:433)
at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
at org.jgroups.JChannel.init(JChannel.java:1725)
... 105 more
2011-10-30 22:21:08,181 ERROR [org.springframework.web.context.ContextLoader] (main) Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name
'liferayHibernateSessionFactory' defined in ServletContext resource [/WEB-INF/classes/META-INF/hibernate-spring.xml]:
Invocation of init method failed; nested exception is java.lang.NullPointerException
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)

I have updated the ehcache.jar, ehcache-sessionreplication.jar and jgroup.jar files to their latest release versions. Of course, I have used custom configuration files for Hibernate cache replicationa nd multi-vm cache replication.

Can you give me some advice for this issue?
Hi Robert,

I don't remember off the top of my head, but it seems you are sending UDP packets, which TCP unicast does not accept.
@Edward Han

How to enable RMI ehcache replication in liferay 6.1.0? In source code I see that cache listeners are cleared when cluster link is disabled.
Hi EDWARD,
I have configured Liferay Portal 6.1.20 nodes. We are getting following error .

WARN [net.sf.ehcache.hibernate.strategy.AbstractReadWriteEhcacheAccessStrategy] (http--0.0.0.0-8080-104) Cache com.liferay.portlet.documentlibrary.model.impl.DLFileEntryImpl Key com.liferay.portlet.documentlibrary.model.impl.DLFileEntryImpl#4182245 Lockable : null
A soft-locked cache entry was expired by the underlying Ehcache. If this happens regularly you should consider increasing the cache timeouts and/or capacity limits

I have following queries
1. Is this affects portal performance.
2. How to overcome such errors?

Need you help.

Thanks