Thanks for the answers to my previous question about getting a callback if the cluster goes down. We decided to go with EndpointListener in the short term as we’re still on Gemfire 7.0.2 (I forgot to mention that). We’re going to upgrade soon though and then we’ll move to ClientMembershipListener as it’s a public API.
I have some related questions – here’s some background: We have a cluster of Gemfire servers and a number of Replicated regions. We have a microservice architecture where all of our applications are publishers for some regions and clients for other regions. We use CQs for most if not all of the client scenarios. Because of the CQ requirement all of our applications are clients. In one of these applications (called Trade Server) we would like to avoid needing to have it reload its region in the cluster if the cluster goes down completely and comes back up. I discussed with my colleagues the possibility of making the Trade Server a peer instead of a client. It could be a replica for its region and then it would not be impacted if the main cluster went down. And then when the cluster came back up Trade Server would replicate its data back to it. The only glitch is that it is a client for other regions. I told them that instead of using CQs in Trade Server we could use CacheListeners (still determining whether any query is more complicated than select * from /otherRegion). They are hesitant because they are attached to CQs. Does this sound reasonable to you? Something that has caused us a bit of pain in the past is the fact that one JVM can either be a Client or a Peer, but not both. And you can’t have multiple instances of ClientCache since it uses statics. The latter was a problem in our microservices architecture as each service has its own client API, but each client API can’t have its own ClientCache. We worked around it by wrapping ClientCache and making the wrapper API a singleton. But there are still some gotchas, like if two services use different PDX serialization configs, etc. Is that something you have been thinking about fixing for the future? That is, making it so, in one JVM, you can have multiple clients/peers? With microservices becoming a bigger trend I think more people will want that. Thanks, -- Eric
