Hi Barry - The CQs are on other regions and they are doing puts on the main Trade region. The Trade region is Replicated in the cluster and the Trade Server has a CACHING_PROXY client region.
Thanks for the tip on the the CacheListener queue monitoring. -- Eric On Tue, Sep 29, 2015 at 7:32 PM, Barry Oglesby <[email protected]> wrote: > One thing I wanted to clarify is how you're loading the data in the Trade > Server client now. Are you doing puts from the CqListener into a local > region? > > Also, one thing to be careful about with asynchronous CacheListeners is > they tend to hide memory usage if the thread pool can't keep up with the > tasks being executed. At the very least, make sure to monitor the size of > the thread pool's backing queue. > > Barry Oglesby > GemFire Advanced Customer Engineering (ACE) > For immediate support please contact Pivotal Support at > http://support.pivotal.io/ > > > On Tue, Sep 29, 2015 at 6:06 AM, Eric Pederson <[email protected]> wrote: > >> Thanks Barry. That makes a lot of sense. With power comes great >> responsibility... It sounds like we would want to have the CacheListener be >> asynchronous, adding events to a queue that that the application code pulls >> from. >> >> >> -- Eric >> >> On Mon, Sep 28, 2015 at 10:06 PM, Barry Oglesby <[email protected]> >> wrote: >> >>> 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 >>>> >>> >>> >> >
