Spring Data GemFire Region entry expiration (Time-To-Live) error

Question

I have a Spring Data GemFire Region that's configured using annotations below:

@TimeToLiveExpiration(timeout = "100", action = "INVALIDATE")
@PartitionRegion(name = "blockedIPCache")
class BlockedIpEntityType { ... }

My application is a Spring Boot application and I used the following annotations to configure SDG:

@PeerCacheApplication
@EnableGemfireCaching
@EnableCachingDefinedRegions(clientRegionShortcut = ClientRegionShortcut.LOCAL, serverRegionShortcut = RegionShortcut.LOCAL)
@EnableStatistics
@EnableExpiration
@EnableEntityDefinedRegions(basePackageClasses = {...})
@EnableGemfireRepositories(basePackages = {...})
class GemFireConfiguration { ... }

All I want is to insert an object using a Spring Data GemFire Repository and after awhile the entry will be invalidated.

But, I face this Exception when I start my application...

Caused by: java.lang.IllegalStateException: Cannot set idle timeout when statistics are disabled.
    at org.apache.geode.internal.cache.AbstractRegion.setCustomEntryIdleTimeout(AbstractRegion.java:1157) ~[geode-core-9.1.1.jar:?]
    at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$ExpirationPolicyMetaData.configure(ExpirationConfiguration.java:511) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
    at org.springframework.data.gemfire.config.annotation.ExpirationConfiguration$1.postProcessAfterInitialization(ExpirationConfiguration.java:160) ~[spring-data-gemfire-2.0.6.RELEASE.jar:2.0.6.RELEASE]
...

This happens exactly when Spring tries to autowire my Repository related to the Region configured above.

So what I'm doing wrong? And, is there a way to enable Region statistics using Java configuration or Annotations?

Note: Using Spring Data GemFire 2.0.6, Spring 5.0.5, Spring Boot 2.0.1 used in the project.

Answer 1

It turns out, you did not do anything wrong. Unfortunately, you stumbled across a bug(!), for which I have already filed SGF-747 and fixed. I am sorry for the inconvenience this issue may have caused you.

We are planning a Spring Data Lovelace M3 (Milestone 3) release tomorrow (Thursday, 5/17, CET). The release schedule is visible from Spring Release Calendar. All dates are tentative.

As such, you could try the new Spring Data for Pivotal GemFire (SDG) Lovelace bits (i.e. 2.1.0.M3) with the fix. SDG 2.1.0. should work just fine with Spring Boot 2.0.1/2.RELEASE and Spring 5.0.5/6.RELEASE.

However, if you are expecting to get GA bits for SDG containing this fix, then you will have to wait for the next Spring Data Kay Service Release (Kay SR8), or the Spring Data for Pivotal GemFire 2.0.8 Service Release. I am backing porting this fix.

Unfortunately, there is not another Spring Data Kay Service Release (i.e. Kay SR8) planned until probably around July 2nd or 3rd, right after Spring Framework 5.0.7 is released on Monday, July 2nd and just before Spring Boot 2.0.3 is released on Wednesday, July 4th, which is usually when we plan Spring Data Service Releases. Also, know that Spring Boot 2.0.x is based on Spring Data Kay, but should work just fine with SD Lovelace too, as I mentioned previously.

In the meantime, I will try to think of workaround where the convenience of the Annotations (e.g. @EnableEntityDefinedRegions) can still be used. I will post the workaround in SGF-747.

I see that you specified the clientRegionShortcut attribute in the @EnableCachingDefinedRegions annotation but have declared your application to be a @PeerCacheApplication. While there is no harm in doing so, the clientRegionShortcut attribute is useless in this case. Likewise, the serverRegionShortcut attribute would have no meaning if you are application were a @ClientCacheApplication instead; something to keep in mind.

Lastly, I wanted to let you know that the SDG @EnableStatistics annotation does not have the effect you probably think it does.

Specifically, SDG's @EnableStatistics annotation is concerned with enabling Pivotal GemFire's statistics "sampling" as explained here, which is configured by doing this, as also explained in the SDG @EnableStatistics annotation Javadoc, as well as referenced in the SDG Reference Guide.

The "statistics enabling" that ultimately needs to happen is by setting the Region's staticsEnabled attribute property when configuring and creating the Region (e.g. "blockedIPCache").

That is exactly what the @EnableExpiration annotation will indirectly guarantee now, with the fix in SGF-747, without the need to @EnableStatistics.

Anyway, I hope this all makes sense and helps.

Regards, John