Bloggers recientes

Sandeep Sapra

2 Mensajes
17 de noviembre de 2017

Zeno Rocha

17 Mensajes
7 de noviembre de 2017

Yasuyuki Takeo

3 Mensajes
5 de noviembre de 2017

John Feeney

1 Mensajes
3 de noviembre de 2017

Gregory Amerson

30 Mensajes
3 de noviembre de 2017

Minhchau Dang

13 Mensajes
3 de noviembre de 2017

Petteri Karttunen

5 Mensajes
30 de octubre de 2017

Alex Swain

2 Mensajes
27 de octubre de 2017

Jamie Sammons

10 Mensajes
23 de octubre de 2017

Jan Verweij

2 Mensajes
23 de octubre de 2017

Ehcache configuration changes

Company Blogs 27 de septiembre de 2011 Por 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, 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 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.

Mostrando 1 resultado.