The use of static state for the Geode cache in a JVM process is a terribly limiting factor and there is not much excuse to have that in Geode nowadays. We had to fight hard this limitation in many projects.
So, voting up for the GEODE-395 <https://issues.apache.org/jira/browse/GEODE-395> ! Best Regards, Sergey On Tue, Oct 13, 2015 at 8:33 PM, Barry Oglesby <[email protected]> wrote: > Eric, > > This idea definitely works. Here are some parts of an example. If you want > the whole thing, let me know. > > Create your client xml with 2 pools like: > > <client-cache> > > <pool name="uat" subscription-enabled="true"> > <locator host="localhost" port="12341"/> > </pool> > > <pool name="prod" subscription-enabled="true"> > <locator host="localhost" port="12342"/> > </pool> > > </client-cache> > > Then register your CQs against each pool like: > > private void registerCqs() throws Exception { > registerCq("uat"); > registerCq("prod"); > } > > private void registerCq(String poolName) throws Exception { > // Get the query service > QueryService queryService = ((ClientCache) > this.cache).getQueryService(poolName); > > // Create CQ Attributes > CqAttributesFactory cqAf = new CqAttributesFactory(); > > // Initialize and set CqListener > CqListener[] cqListeners = {new TestCqListener(poolName)}; > cqAf.initCqListeners(cqListeners); > CqAttributes cqa = cqAf.create(); > > // Construct a new CQ > String cqName = poolName + "_cq"; > String cqQuery = "SELECT * FROM /data"; > CqQuery cq = queryService.newCq(cqName, cqQuery, cqa); > cq.execute(); > System.out.println("Registered pool=" + poolName + "; cq=" + cqName + "; > query=" + cqQuery); > } > > > Barry Oglesby > GemFire Advanced Customer Engineering (ACE) > For immediate support please contact Pivotal Support at > http://support.pivotal.io/ > > > On Tue, Oct 13, 2015 at 6:07 AM, Eric Pederson <[email protected]> wrote: > >> Hi Anil - thanks, I will try that and get back to you. >> >> >> -- Eric >> >> On Mon, Oct 12, 2015 at 6:21 PM, Anilkumar Gingade <[email protected]> >> wrote: >> >>> Are you looking at connecting client to multiple environments (servers >>> in dev, UAT, prod...) and getting the events...If this is the case, one >>> option to try is, create client connection pools to different environment >>> and register CQs using those pools...(I haven't tried this, but I think its >>> doable)... >>> >>> -Anil.. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Oct 12, 2015 at 1:44 PM, Eric Pederson <[email protected]> >>> wrote: >>> >>>> Hi all - >>>> >>>> I logged https://issues.apache.org/jira/browse/GEODE-395 as a feature >>>> request to support multiple Caches per JVM. One thing I forgot in my >>>> earlier email and is probably the biggest pain point with the current >>>> limitation is the ability to connect to multiple environments at the same >>>> time. For example, we will to connect to UAT for most services, but we'll >>>> want to point one service in particular to Dev for debugging, or maybe >>>> point it to Prod to get some live data. >>>> >>>> Thanks, >>>> >>>> >>>> -- Eric >>>> >>>> On Wed, Sep 30, 2015 at 11:37 AM, Eric Pederson <[email protected]> >>>> wrote: >>>> >>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
