This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Strange behavior using CrudRepository (also GemfireRepository)

Feb 22nd, 2013, 10:43 AM

I've been playing around with the new Spring-Gemfire project and have gotten most to work pretty smoothly. However, I have run into one problem using the CrudRepository and GemfireRepository interfaces. Let me set up the problem.

Finally, here are my tests. I was able to do some basic fetches and queries using the GemfireTemplate with no problem. But in the last test, I get an exception that seems to boil down to this: Region not found: /Accountss

Now, another strange behavior. I tried using the findAll() method (both the one on the CrudRepository and defining my own to return a Set<Account> per some of the examples. While I can invoke accountRepository.count() and get the right number of items back, I can't seem to get anything returned with findAll().

I don't see anything from the documentation that would indicate that anything more than the above is required but maybe I'm still missing something.

Comment

Yes. This is a bit tricky because of the way gemfire works.In a client/server configuration count() does a true count of everything in the distributed grid. findAll() and all similar query methods query the local cache. The local cache does not stay in synch by default, and for many applications that's a good thing because you want to cache locally only data your application specifically uses. So if you call repo.findOne(key) you'll get the object. If your client region is configured to store entries locally (the default) then if you call findAll() again, any retrieved objects will be included. However, this leads to some apparent inconsistencies. If you want the local cache to hold the entire region, then subscribe to all cache keys. Enable subscriptions on the pool and register interest in all keys. configured in Spring as:

Comment

Yes. This is a bit tricky because of the way gemfire works.In a client/server configuration count() does a true count of everything in the distributed grid. findAll() and all similar query methods query the local cache. The local cache does not stay in synch by default, and for many applications that's a good thing because you want to cache locally only data your application specifically uses.

Thanks. You confirmed what I was just coming to the conclusion of based on stepping through the code into the bowels of SimpleGemfireRepository, etc. At the end of the day, it invokes region.values(), which in the case of client regions would only return values in the local cache. I should have known I guess but didn't think about how the query was performed.

This kind of detail might be helpful in the JavaDocs for these classes.

Thanks again.

Comment

Actually, I changed findAll() to be consistent with count. I think for the repository abstraction, it makes more sense. You can use other APIs to find out what's in local cache. This won't require any special configuration. see https://jira.springsource.org/browse/SGF-163. Thanks for the feedback

Comment

Ok - just got a chance to try migrating to the latest 1.3.0.RELEASE version. However, I tried simply changing the version and I'm getting ArtifactDescriptorExceptions. This is always difficult to trace down to the source but I can use 1.3.0.BUILD-SNAPSHOT and things work. Changing to 1.3.0.RELEASE gives me errors regarding 'failure to read artifact descriptor for gemfire 7.0.1'. This isn't in some other repository is it?