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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
