Effects of changing 'expiration-attributes timeout' value using 'alter region' command through gfsh.

Products

• VMware Tanzu Gemfire

Issue/Introduction

This article describes about effects of changing 'expiration-attributes timeout' value using 'alter region' command through gfsh.

Environment

Product Version: 8.1

Resolution

Restart of a existing member or adding a new member fails during start-up phase after changing 'expiration-attributes timeout' value using 'alter region' command. Same behavior also noticed in adding a cache writer through 'alter region' command in gfsh.

Different behaviors can be seen according to cluster configuration is enabled or not.

Case-1: enable-cluster-config=false

Let's say 'expiration-attributes timeout' was initially set to 200 in cache.xml and later it was modified to 300 using alter region command in gfsh.

alter region --name=/<Region-Name> --entry-time-to-live-expiration=300

Post to this change a member was gracefully stopped then 'expiration-attributes timeout' is modified to 300 in cache.xml. Now starting the member fails with the below exception:

Exception in thread "main" java.lang.IllegalStateException: The entry time to live set in RegionAttributes is incompatible with entry time to live used by other distributed members.

When cluster configuration is disabled,  a member reads the configuration from cache.xml during start-up. Note that at this moment, all the running members have 'expiration-attributes timeout' to 300 and restarted member has 300 in it's cache.xml but still it fails to start with above exception. Adding a new member at this moment with 'expiration-attributes timeout=300' also fails.

Workaround:

- Keep the old value for 'expiration-attributes timeout' in cache.xml i.e. 200 in this case.

- Start the stopped member or the new member.

- Once the member is up and running execute the 'alter region' command again to sync this member's expiration-attributes timeout' value with other running members.

Case-2: enable-cluster-config=true

In this case, a member fetches the cluster configuration from the locator instead of reading from the cache.xml. Any modification to cluster configuration is preserved by the locator. The locator provides the updated value for 'expiration-attributes timeout' but still the member start-up fails after a graceful stop or if it is a new member. No workaround is currently available.

=============================
[info 2015/06/03 10:19:07.139 PDT server3 <main> tid=0x1] Received cluster configuration from the locator
[info 2015/06/03 10:19:07.183 PDT server3 <main> tid=0x1] 
***************************************************************
Configuration for 'cluster'

Jar files to deployed
<?xml version="1.0" encoding="UTF-8"?>
<cache xsi:schemaLocation="http://schema.pivotal.io/gemfire/cache http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd" lock-lease="120" lock-timeout="60" search-timeout="300" is-server="false" copy-on-read="false" version="8.1" xmlns="http://schema.pivotal.io/gemfire/cache" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<region name="Customer">
<region-attributes data-policy="partition" statistics-enabled="true">
<entry-time-to-live>
<expiration-attributes timeout="300" action="destroy"/>
</entry-time-to-live>
<partition-attributes redundant-copies="1" recovery-delay="50000"/>
</region-attributes>
</region>
</cache>
===============================