« Back

Ehcache configuration changes

Company Blogs September 27, 2011 By Edward Han Staff

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.

Threaded Replies Author Date
Nice summary! Thank you, Edward. Jonas Yuan September 27, 2011 11:08 AM
Thanks for the update. One question though. Is... Pius Onobhayedo September 28, 2011 4:57 AM
Cluster Link is part of the core portal and... Edward Han September 28, 2011 8:33 AM
Thanks Edward for the prompt reply. If I... Pius Onobhayedo September 28, 2011 9:00 AM
That is correct Edward Han October 3, 2011 1:29 PM
Thanks for the update Ed! Shagul Khajamohideen October 4, 2011 6:43 AM
Hi, Edward, I want to tell you what I like... Xinsheng Robert Chen October 11, 2011 3:41 PM
Hi Edward, I am trying to test ehcache... Pius Onobhayedo October 12, 2011 12:06 PM
Hi Edward, Please ignore my last question. I... Pius Onobhayedo October 13, 2011 8:52 AM
Hi, Edward, I have configured a cluster of two... Xinsheng Robert Chen November 3, 2011 9:18 PM
Hi Robert, I don't remember off the top of my... Christopher Lui December 28, 2011 9:54 PM
@Edward Han How to enable RMI ehcache... Krzysztof Makowski November 14, 2012 12:53 AM
Hi EDWARD, I have... Sushil Patidar February 21, 2014 3:07 AM

Nice summary! Thank you, Edward.
Posted on 9/27/11 11:08 AM.
Thanks for the update. One question though. Is Cluster Link deployed or bundled with the portal by default?
Posted on 9/28/11 4:57 AM.
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
Posted on 9/28/11 8:33 AM in reply to Pius Onobhayedo.
Thanks Edward for the prompt reply. If I understood you correctly, while only EE ships with Cluster Link-based replication, CE can only use RMI-based replication. Am I right?
Posted on 9/28/11 9:00 AM in reply to Edward Han.
That is correct
Posted on 10/3/11 1:29 PM in reply to Pius Onobhayedo.
Thanks for the update Ed!
Posted on 10/4/11 6:43 AM.
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."
Posted on 10/11/11 3:41 PM in reply to Shagul Khajamohideen.
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.

Posted on 10/12/11 12:06 PM in reply to Xinsheng Robert Chen.
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.

Posted on 10/13/11 8:52 AM in reply to Pius Onobhayedo.
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 (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
201­1-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:
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(JGroups­CacheManagerPeerProvider.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(CacheProviderWra­pper.java:62)
at com.liferay.portal.dao.orm.hibernate.EhCacheProvider.start(EhCacheProvider.java:­67)
at org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge.start(RegionFac­toryCacheProviderBridge.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(Loc­alSessionFactoryBean.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.ini­tializeBean(AbstractAutowireCapableBeanFactory.java:1420)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doC­reateBean(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?
Posted on 11/3/11 9:18 PM in reply to Pius Onobhayedo.
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.
Posted on 12/28/11 9:54 PM in reply to Xinsheng Robert Chen.
@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.
Posted on 11/14/12 12:53 AM in reply to Christopher Lui.
I have configured Liferay Portal 6.1.20 nodes. We are getting following error .

WARN [net.sf.ehcache.hibernate.strategy.AbstractReadWriteEhcacheAccessStrategy] (http-- 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.

Posted on 2/21/14 3:07 AM.