Configure Data Expiration

This topic explains how to configure data expiration in VMware Tanzu GemFire.

Configure the type of expiration and the expiration action to use.

• Expiration actions require setting the region attribute of statistics-enabled to true. This can be done in the region element of a cache.xml file, the gfsh command line, or through the API.

• Set the expiration attributes by expiration type, with the max times and expiration actions. See the region attributes listings for entry-time-to-live, entry-idle-time, region-time-to-live, and region-idle-time in <region-attributes>.

The statistics used for expiration are available directly to the application through the CacheStatistics object returned by the Region and Region.Entry getStatistics methods. The CacheStatistics object also provides a method for resetting the statistics counters.

For partitioned regions:

• On a partitioned region, expiration is supported only for the region’s entries, not for the region itself. Region-wide expiration attributes, such as region-time-to-live and region-idle-time do not apply to the data items in partitioned regions.
• To ensure reliable read behavior when working with partitioned regions, use the entry-time-to-live attribute, not the entry-idle-time attribute.
• You cannot use local-destroy or local-invalidate expiration actions in partitioned regions.

Replicated regions example:

// Setting standard expiration on an entry
<region-attributes statistics-enabled="true"> 
  <entry-idle-time> 
    <expiration-attributes timeout="60" action="local-invalidate"/> 
  </entry-idle-time> 
</region-attributes> 

• Override the region-wide settings for specific entries, if required by your application. To do this:

  1. Program a custom expiration class that implements org.apache.geode.cache.CustomExpiry. Example:

     // Custom expiration class
     // Use the key for a region entry to set entry-specific expiration timeouts of 
     //   10 seconds for even-numbered keys with a DESTROY action on the expired entries
     //   Leave the default region setting for all odd-numbered keys. 
     public class MyClass implements CustomExpiry, Declarable 
     { 
         private static final ExpirationAttributes CUSTOM_EXPIRY = 
                 new ExpirationAttributes(10, ExpirationAction.DESTROY); 
         public ExpirationAttributes getExpiry(Entry entry) 
         { 
             int key = (Integer)entry.getKey(); 
             return key % 2 == 0 ? CUSTOM_EXPIRY : null; 
         }
     }
     

  2. Define the class inside the expiration attributes settings for the region. Example:

     <!-- Set default entry idle timeout expiration for the region --> 
     <!-- Pass entries to custom expiry class for expiration overrides -->
     <region-attributes statistics-enabled="true"> 
         <entry-idle-time> 
             <expiration-attributes timeout="60"> 
                 <custom-expiry> 
                     <class-name>com.company.mypackage.MyClass</class-name> 
                 </custom-expiry> 
             </expiration-attributes> 
         </entry-idle-time> 
     </region-attributes>
     

  The gfsh equivalent of the above XML is:

  gfsh> create region --name=region1 --type=REPLICATE --enable-statistics \
  --entry-idle-time-expiration=60 --entry-idle-time-custom-expiry=com.company.mypackage.MyClass
  

• When the primary expires entries, it requests last-accessed statistics from the secondaries. The primary adopts the most recent access time and reschedules the expiration, if warranted. This is done only for distributed expiration actions, and applies to both partitioned and replicated regions.

You can also configure regions using the gfsh command-line interface. See Region Commands.

Configuring the Number of Threads for Expiration

You can use the gemfire.EXPIRY_THREADS system property to increase the number of threads that handle expiration. By default, one thread handles expiration, and it is possible for the thread to become overloaded when entries expire faster than the thread can expire them. If a single thread is handling too many expirations, it can result in an OOME. Set the gemfire.EXPIRY_THREADS system property to the desired number when starting the cache server.