The big difference between a peer and a client is that the peer is a member of the distributed system whereas the client is not. This means, among other things, that CacheListener callbacks are synchronous with the original operation whereas CqListener callbacks are not. When the Trade Server peer is started, your application put performance may degrade depending on what is done in the CacheListener callback.
You'll have synchronous replication of data between the server and peer as well, but if the client's queue is on a node remote to where the operation occurs, then that is also a synchronous replication of data. So, that more-or-less balances out. Also, the health of a Trade Server peer can affect the other distributed system members to a greater degree than a client. For example, operations being replicated to the Trade Server peer will be impacted if a long GC is occurring in it. Barry Oglesby GemFire Advanced Customer Engineering (ACE) For immediate support please contact Pivotal Support at http://support.pivotal.io/ On Mon, Sep 28, 2015 at 3:33 PM, Eric Pederson <[email protected]> wrote: > 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 >
