geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Baker (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (GEODE-520) GFSH Alter Region entry-time-to-live-expiration causes subsequent server restart to fail.
Date Fri, 15 Jan 2016 06:14:56 GMT

     [ https://issues.apache.org/jira/browse/GEODE-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anthony Baker closed GEODE-520.
-------------------------------

> GFSH Alter Region entry-time-to-live-expiration causes subsequent server restart to fail.
> -----------------------------------------------------------------------------------------
>
>                 Key: GEODE-520
>                 URL: https://issues.apache.org/jira/browse/GEODE-520
>             Project: Geode
>          Issue Type: Bug
>          Components: management
>    Affects Versions: 1.0.0-incubating.M1
>            Reporter: Jens Deppe
>            Assignee: Jens Deppe
>              Labels: gfsh
>             Fix For: 1.0.0-incubating.M1
>
>
> h4. Summary
> Example: alter region --name=/<Region-Name> --entry-time-to-live-expiration=<time
in seconds>
> The above command execution causes unexpected behaviors in different cluster configurations
setup. Scenario-1 provides some options to keep the cluster running but scenario-2 makes the
cluster completely unstable.
> h4. Scenario 1 (enable-cluster-configuration=false)
> Restarting an exiting server or Adding a new server fails with new timeout value that
was already successfully applied to 'entry-time-to-live-expiration' value on a partitioned
region at runtime through gfsh.
> Steps to Reproduce:-
> # In cache.xml add below xml fragment inside {{<region-attributes>}} element for
a partitioned region.
> {noformat}
> <entry-time-to-live><expiration-attributes timeout="300" action="destroy"/></entry-time-to-live>
> {noformat}
> # Start the locator using {{--enable-cluster-configuration=false}}
> # Start 2-3 servers using the cache.xml. Let's say server1, server2, server3
> # Execute {{alter region --name=/<Region-Name> --entry-time-to-live-expiration=200}}
in gfsh and notice new value updated to all the running server.
> {noformat}
> gfsh>alter region --name=/Customer --entry-time-to-live-expiration=200
> Member | Status
> server1 | Region "/Customer" altered on "server1"
> server2 | Region "/Customer" altered on "server2"
> server3 | Region "/Customer" altered on "server3"
> {noformat}
> # Stop server2. Modify the cache.xml to have the new timeout value of 200 as the running
servers are already having new timeout value of 200 for the regions.
> # Start the server2 and notice server start-up fails with below error.
> {noformat}
> 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.
> at com.gemstone.gemfire.internal.cache.PartitionRegionConfigValidator?.validateExpirationAttributes(PartitionRegionConfigValidator?.java:198)
> {noformat}
> # Revert back the timeout to old value of 300. Start server2 and notice server2 will
start without any issue though timeout value is different that other cluster members.
> # Adding a new server also behaves same as restarting an existing server described in
Step-6 and Step-7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message