How to define new caches in plugins

Version 2

    Caches are used for storing information in memory. When running in a cluster caches are dynamically modified so that their content is replicated in all nodes (aka optimistic ) or to have their content distributed across the cluster nodes (aka distributed ). Even when running in standalone mode caches need to be configured to have a certain max size and expiration time. This document explains how to create and configure caches while developing plugins.

     

    First of all you need to create a file named cache-config.xml and place it in the root folder of your plugin. The new file will live next to the plugin.xml and the other html files. In the cache-config.xml we are going to define the caches that the plugin will create and how those caches should be configued.

     

    Here is an example of the content inside the new file.

    <cache-config>
        <cache-mapping>
            <cache-name>Example Session Location Cache</cache-name>
            <scheme-name>optimistic</scheme-name>
            <init-params>
                <init-param>
                    <param-name>back-size-high</param-name>
                    <param-value>0</param-value>
                </init-param>
                <init-param>
                    <param-name>back-expiry</param-name>
                    <param-value>0</param-value>
                </init-param>
                <init-param>
                    <param-name>back-size-low</param-name>
                    <param-value>0</param-value>
                </init-param>
            </init-params>
        </cache-mapping>
    </cache-config>
    

     

    All caches should be defined inside the cache-config element. Each cache is defined by the cache-mapping element. The cache-name element defines the name of the cache and that is what will appear when viewing the list of caches in the admin console. The scheme-name is only used when running in a cluster. Possible values are optimistic and distributed. The former indicates that the content of the cache will be replicated in all cluster nodes. This is good for frequent read operations with not frequent write operations. However, since content is copied to all nodes it is not good if the cache content will consume lots of memory. On the other hand, the distributed schema defines that the cache content will be distributed across the node and by default Openfire will copy the content of each cluster node in another node to avoid a single point of failure.

     

    The next three init-param elements should be present for each cache. The back-size-high parameter defines the maximum size in bytes for the cache. When the cache tries to exceed that size content from the cache will be removed and it will try to go to the size defined by the back-size-low parameter. The back-expiry parameter defines the time a content can stay in the cache before it is removed. The expiration time can be defined in minutes (e.g. 30m) or in hours (e.g. 2h) or in days (e.g. 2d). Using a value of zero in any of these parameters is a way to set no limit or expiration time.