Re-replying to all for everyone's benefit. See *comments* below... On Thu, Jan 11, 2018 at 11:35 AM, John Blum <[email protected]> wrote:
> Comments below... > > On Thu, Jan 11, 2018 at 12:04 AM, Dharam Thacker < > [email protected]> wrote: > >> Hello John, >> >> Thank you for your reply! Few more comments on that in *RED* >> >> *> Do i still need below code? As we can not give multiple pools in >> <gfe:client-cache> element so unnecessarily we have to create locatorPool >> as well* >> >> >> The only thing that <gfe:client-cache pool-name="MyPool"/> does is, >> configure the "DEFAULT" Apache Geode *Pool* using the configuration >> settings of the "named" *Pool* bean (i.e. "MyPool") defined in your >> *Spring* config. >> >> >> >> This is only necessary when you have defined "client" *Regions* >> *without* an explicit *Pool*, like so... >> >> >> <gfe:client-region id="Example" shortcut="PROXY"/> >> >> >>> Let's take below example *where I don't need any gfe:client regions* >> in my client code as i just have QueryService instance created from Pool >> instance >> >> <gfe:pool id="myPool1" server-group="s1" subscription-enabled="true" >> locators="${myapp.geode.locators}"> >> >> <gfe:pool id="myPool2" server-group="s2" subscription-enabled="true" >> locators="${myapp.geode.locators}"> >> >> QueryService qs1 = myPool1.getQueryService(); >> >> QueryService qs12 = myPool2.getQueryService(); >> >> >> >> *How I can set geodeProperties like log-level,security-username etc >> without have gfe:client-cache in pool itself? As you explained i can skip >> creating client cache instance but then how we can provide security >> properties?* >> >> > No, I did not say you could skip creating a *ClientCache*. > > >> >> *In fact spring SDG complains if client cache singleton is not present >> here* >> >> > You cannot have a *Pool* without a *ClientCache*. A *Pool* requires the > presence of a *DistributedSystem* (yes, even on a client) [1], which is > created by the (client) cache [2]. > > Additionally, it is not SDG that complains, it is Apache Geode as it is a > Geode requirement. > > [1] https://github.com/apache/geode/blob/rel/v1.3.0/geode- > core/src/main/java/org/apache/geode/cache/client/internal/ > PoolImpl.java#L217-L222 > [2] https://github.com/apache/geode/blob/rel/v1.3.0/geode- > core/src/main/java/org/apache/geode/cache/client/ > ClientCacheFactory.java#L241-L242 > > > >> >> *> 3. 3.2 Can we create 2 proxy regions for that single partitioned >> region defined in both server group using same name in each pool?* >> >> >> Do you mean... >> >> // server >> <gfe:partitioned-region id="Example" .../> >> >> // client >> <gfe:client-region id="ExampleOne" name="Example" shortcut="PROXY" >> pool-name="myPool1"/> >> >> <gfe:client-region id="ExampleTwo" name="Example" shortcut="PROXY" >> pool-name="myPool2"/> >> >> Hmm, I am not sure actually; I have never tried this. >> >> I think *Spring* will complain because 2 different uniquely identified >> client *Regions* ("ExampleOne" and "ExampleTwo") beans have the same >> name ("Example"), where the "name" attribute is actually a *Spring* bean >> "*alias*". >> >> Even if *Spring* did not complain when creating the client *Region* bean >> definitions, Apache Geode is going to complain when you try to create 2 >> *Regions* with the same name since... >> >> <gfe:client-region> >> >> Ultimately results in... >> >> clientCache.createClientRegionFactory(..).create("Example") // for >> ExampleOne >> clientCache.createClientRegionFactory(..).create("Example") // for >> ExampleTwo >> >> Because the "name" of the client *Region* must match the server *Region* and >> you cannot define 2 *Regions* with the same name. >> >> Am I understanding your question correctly? >> >> *>>> Yes you are right. That's what I am asking for. In that case, can i >> say that if we have partitioned region/replicated region then it can not be >> used across server groups for handling CQEvents?* >> >> *Is that true?* >> >> > No, that is not true! > > If you do not need client *Regions*, then there really is no point if all > your application is doing it registering CQs (i.e. the application a > passive listener responding to/acting on events), then you simply can > define 2 Pools for each server group and define a CQ from each of those > Pools. > > I have a similar example here [3]. This Spring Boot, Apache Geode client > cache application [4] (connecting to a Locator on the default host/port) > simply registers a CQ [5] without any client Region defined. The server > does register the "Chat" *Region* [6]. The only difference is that my > example is not using multiple server Regions in different groups where the > client uses a Pool per group. > > Still you need a *ClientCache* for reasons I mention above. > > > [3] https://github.com/jxblum/contacts-application/blob/ > master/continuous-query-example/src/main/java/example/ > app/geode/cache/observer/ChatClientListenerApplication.java > [4] https://github.com/jxblum/contacts-application/blob/ > master/continuous-query-example/src/main/java/example/ > app/geode/cache/observer/ChatClientListenerApplication.java#L41 > [5] https://github.com/jxblum/contacts-application/blob/ > master/continuous-query-example/src/main/java/example/ > app/geode/cache/observer/ChatClientListenerApplication.java#L56 > [6] https://github.com/jxblum/contacts-application/blob/ > master/continuous-query-example/src/main/java/example/ > app/geode/cache/server/ChatBotServerApplication.java#L60-L72 > > >> >> *Thanks,* >> *Dharam* >> >> - Dharam Thacker >> >> On Wed, Jan 10, 2018 at 10:53 PM, John Blum <[email protected]> wrote: >> >>> Hi Dharam- >>> >>> Regarding... >>> >>> *> 1. What is the best way to handle multiple pools each connecting to >>> unique server group though sharing same set of locators?* >>> >>> <gfe:pool id="locatorPool" server-group="s1" subscription-enabled= >>> "true" >>> locators="host[port1],host2[port2],...,hostN[portN]"> >>> >>> I.e. you use the "locators" attribute instead of the nest <gfe:locator> >>> xor <gfe:server> elements. The "locators" attribute follows the same >>> syntax as the Geode "locators" property, as demonstrated above. You >>> can even externalize the value for the "locators" attribute using >>> *Spring* SpEL expressions or property placeholders (complete with >>> default values in case the property was not defined, if you desire), e.g. >>> ... >>> >>> <gfe:pool id="locatorPool" server-group="s1" subscription-enabled= >>> "true" >>> locators="${myapp.geode.locators:localhost[10334],localhos >>> t[10335]}"> >>> >>> So, you can solve your problem like so... >>> >>> <util:properties id="applicationProperties"> >>> <prop key="myapp.geode.locators">boombox[10334],cardboardbox[11235 >>> ],mailbox[12480]</prop> >>> ... >>> </util:properties> >>> >>> <gfe:pool id="myPool1" server-group="s1" subscription-enabled="true" >>> locators="${myapp.geode.locators}"> >>> >>> <gfe:pool id="myPool2" server-group="s2" subscription-enabled="true" >>> locators="${myapp.geode.locators}"> >>> >>> Also, rather than defining the "myapp.geode.locators" property in XML, >>> you can externalize it using any of *Spring's* conventions for >>> configuration, i.e. property sources, etc. >>> >>> >>> >>> *> Do i still need below code? As we can not give multiple pools in >>> <gfe:client-cache> element so unnecessarily we have to create locatorPool >>> as well* >>> >>> The only thing that <gfe:client-cache pool-name="MyPool"/> does is, >>> configure the "DEFAULT" Apache Geode *Pool* using the configuration >>> settings of the "named" *Pool* bean (i.e. "MyPool") defined in your >>> *Spring* config. >>> >>> This is only necessary when you have defined "client" *Regions* >>> *without* an explicit *Pool*, like so... >>> >>> <gfe:client-region id="Example" shortcut="PROXY"/> >>> >>> Because the "Example" client *Region* is a PROXY (applies to >>> CACHING_PROXY as well; essentially any client *Region* that would >>> result in sending the data op to the Geode cluster) but does *not* name >>> an "explicit" *Pool* using the pool-name="LocatorsPool" attribute, then >>> that client *Region* is going to use the "DEFAULT" *Pool*. By default, >>> Apache Geode configures the "DEFAULT" *Pool* to connect to a single >>> server on "localhost", port "40404". That is intrinsic to Apache >>> Geode, not something SDG does. >>> >>> So, in your example above, if your *Pool* is configured with *Locators* >>> and not *Servers*, or you do not have a *Server* listening on >>> localhost:40404, then all "Example" client *Region* data ops are going >>> to fail. Therefore, you can either configure the DEFAULT *Pool* using >>> a named *Pool* with <gfe:client-cache pool-name="locatorPool"/> or you >>> can configure the *Pool* per client *Region*, <gfe:client-region >>> id="Example" >>> shortcut="PROXY" pool-name="myPool1"/> >>> >>> Make sense? >>> >>> >>> *> 2. Is there any way to handle multiple pools in single data source >>> (gfe-data:datasource)?* >>> >>> NO >>> >>> >>> >>> *> 3. 3.1 If i have partition region(gfe:partitioned-region) defined >>> with same name in both server group s1 & s2 as shown above in point-1, how >>> would CQ events be delivered?* >>> >>> Well, it would depend on how you configured the CQ. >>> >>> As you know, you configure a CQ with the o.a.g.cache.query.QueryService, >>> for example [1]. Of course, using SDG make this quite a bit more >>> convenient, [2] and now, especially with this [3], for example, [4]. >>> >>> If you specify a *Pool* when getting the o.a.g.c.q.QueryService from >>> the *ClientCache* (i.e. clientCache.getQueryService(poolName:String) >>> [5]) then you would restrict all CQ events from the PR coming from a >>> particular server. This might be desired if you are routing particular >>> workloads to specific servers, for instance. The choice is yours and you >>> have a high degree of control. >>> >>> >>> *> 3. 3.2 Can we create 2 proxy regions for that single partitioned >>> region defined in both server group using same name in each pool?* >>> >>> Do you mean... >>> >>> // server >>> <gfe:partitioned-region id="Example" .../> >>> >>> // client >>> <gfe:client-region id="ExampleOne" name="Example" shortcut="PROXY" >>> pool-name="myPool1"/> >>> >>> <gfe:client-region id="ExampleTwo" name="Example" shortcut="PROXY" >>> pool-name="myPool2"/> >>> >>> Hmm, I am not sure actually; I have never tried this. >>> >>> I think *Spring* will complain because 2 different uniquely identified >>> client *Regions* ("ExampleOne" and "ExampleTwo") beans have the same >>> name ("Example"), where the "name" attribute is actually a *Spring* >>> bean "*alias*". >>> >>> Even if *Spring* did not complain when creating the client *Region* >>> bean definitions, Apache Geode is going to complain when you try to create >>> 2 *Regions* with the same name since... >>> >>> <gfe:client-region> >>> >>> Ultimately results in... >>> >>> clientCache.createClientRegionFactory(..).create("Example") // for >>> ExampleOne >>> clientCache.createClientRegionFactory(..).create("Example") // for >>> ExampleTwo >>> >>> Because the "name" of the client *Region* must match the server *Region* >>> and you cannot define 2 *Regions* with the same name. >>> >>> Am I understanding your question correctly? >>> >>> >>> >>> Hope this helps! >>> >>> -John >>> >>> >>> [1] http://geode.apache.org/releases/latest/javadoc/org/apac >>> he/geode/cache/query/QueryService.html#newCq-java.lang.Strin >>> g-java.lang.String-org.apache.geode.cache.query.CqAttributes-boolean- >>> [2] https://docs.spring.io/spring-data/geode/docs/current/re >>> ference/html/#apis:continuous-query >>> [3] https://docs.spring.io/spring-data/geode/docs/current/re >>> ference/html/#bootstrap-annotation-config-continuous-queries >>> [4] https://github.com/jxblum/contacts-application/tree/mast >>> er/continuous-query-example >>> >>> >>> On Wed, Jan 10, 2018 at 4:52 AM, Dharam Thacker < >>> [email protected]> wrote: >>> >>>> Hi Team, >>>> >>>> 1. What is the best way to handle multiple pools each connecting to >>>> unique server group though sharing same set of locators? >>>> >>>> <gfe:pool id="myPool1" subscription-enabled="true" server-group="s1"> >>>> <gfe:locator host="${gemfire.locator.host}" >>>> port="${gemfire.locator.port}"/> >>>> </gfe:pool> >>>> >>>> <gfe:pool id="myPool2" subscription-enabled="true" server-group="s2"> >>>> <gfe:locator host="${gemfire.locator.host}" >>>> port="${gemfire.locator.port}"/> >>>> </gfe:pool> >>>> >>>> Do i still need below code? As we can not give multiple pools in >>>> <gfe:client-cache> element so unnecessarily we have to create locatorPool >>>> as well >>>> >>>> <gfe:pool id="locatorPool"> >>>> <gfe:locator host="${gemfire.locator.host}" >>>> port="${gemfire.locator.port}"/> >>>> </gfe:pool> >>>> >>>> <gfe:client-cache pool-name="localtor-pool" /> >>>> >>>> 2. Is there any way to handle multiple pools in single data source >>>> (gfe-data:datasource)? >>>> >>>> >>>> 3. With Single spring data geode client >> >>>> 3.1 If i have partition region(gfe:partitioned-region) defined with >>>> same name in both server group s1 & s2 as shown above in point-1, how would >>>> CQ events be delivered? >>>> 3.2 Can we create 2 proxy regions for that single partitioned region >>>> defined in both server group using same name in each pool? >>>> >>>> Thanks, >>>> - Dharam Thacker >>>> >>> >>> >>> >>> -- >>> -John >>> john.blum10101 (skype) >>> >> >> > > > -- > -John > john.blum10101 (skype) > -- -John john.blum10101 (skype)
