Subject: Re: Handling multiple server groups in spring data geode client

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:
-John
john.blum10101 (skype)
  John Blum 2018-01-12, 19:36
  Dharam Thacker 2018-01-11, 08:05
  Dharam Thacker 2018-01-10, 12:53