In addition to statics, there is never any excuse for poor encapsulation of state (especially given modern JVM optimizations), which not only makes testing more difficult, but also makes a class less extensible.
On Wed, Oct 14, 2015 at 10:13 AM, Dan Smith <[email protected]> wrote: > +1 for getting rid of statics! > > The static cache also makes it harder to write tests that mock a cache, or > have multiple caches in a VM. > > -Dan > > On Wed, Oct 14, 2015 at 9:52 AM, Sergey Shcherbakov < > [email protected]> wrote: > >> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- -John 503-504-8657 john.blum10101 (skype)
