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?In
fact spring SDG complains if client cache singleton is not present here*
*> 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?*
*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],
> localhost[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/
> apache/geode/cache/query/QueryService.html#newCq-java.
> lang.String-java.lang.String-org.apache.geode.cache.query.
> CqAttributes-boolean-
> [2] https://docs.spring.io/spring-data/geode/docs/
> current/reference/html/#apis:continuous-query
> [3] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap-annotation-config-continuous-queries
> [4] https://github.com/jxblum/contacts-application/tree/
> master/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)
>
