Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

Hi, John, I was also surprised with the old behavior. I believe it's a bug that just accidentally served as a "feature". On Fri, Apr 27, 2018 at 3:42 PM, John Blum wrote: > Hi Jinmei- > > Regarding this... > > " > > *So the current behavior is, when a customer starts a server

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

*correction to my last email, I was using java api and not cache.xml On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh wrote: > Hi Jinmei and Naba, > > I don't think you can define two regions with the same name and different > types. We would throw an IllegalStateException for

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

Hi Jinmei and Naba, I don't think you can define two regions with the same name and different types. We would throw an IllegalStateException for the node that tried to create the region second. At least that was the behavior I was seeing when I tried to create a replicate region and a

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

Hi, Naba, I believe this is possible even before, with or without using cluster configuration. That's why we have to say stuff defined using cache.xml is not mean to be a cluster wide configuration. On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag wrote: > With the new

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

With the new implementation, will it allow two different regions with the same exact name to exist in the cluster ? I meant like server A had a cache.xml with region “test” with different properties as to the cache.xml in server B for region “test”. And the locator had an empty cluster config.

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

My point is: we can't keep "mending" the wrong behavior, otherwise we can not move forward. On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao wrote: > So the current behavior is, when a customer starts a server with cache.xml > that has a region defined, and then later on issues a

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

So the current behavior is, when a customer starts a server with cache.xml that has a region defined, and then later on issues a gfsh command `create index` on that region, the command output would be something like: >create index . Member | Status server-1 |

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

I would also ask/remind us to carefully consider anything that might be needed, or required, in the API as well. We must thoughtfully compliment the, or a, API (i.e. programmatically) with anything you can do in/from *Gfsh*. The API is a first class citizen and how most users will consume

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

I talked with Barbara and understand the long term effort to deprecate cache.xml in favor of cluster config and I heartily agree. I think a good step in that direction is to provide a migration tool for users that reads all cache.xml files for current members and store them in cluster config,

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

The decision is to go with the new behavior (I believe :-)). The region does not exist in the cluster configuration to begin with since it's not created using gfsh, so we have no way of checking unless we make an extra trip to the region to find out what kind of region it is, but again different

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

Since we are working on enhancing Lucene support to allow adding a Lucene index to an existing region containing data, I am very interested in the decision here. Like Mike, I also prefer keeping the original behavior of updating cluster config with both the region and the index if it was not there

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

Ok. Yes we do have to take the leap :) Let's keep thinking that way. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the GemFire book here. On Thu, Apr 19, 2018 at 6:29 PM,

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

but this proposed change is one of the effort toward "deprecating cache.xml". I think we've got to take the leap at one point. On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz wrote: > Hmmm...I think I liked the old behavior better. It was a kind of bridge to > cluster

Re: [Proposal]: behavior change when region doesn't exist in cluster configuration

Hmmm...I think I liked the old behavior better. It was a kind of bridge to cluster config. I still think we need to be putting much more effort into deprecating cache.xml and much less effort into fixing the (possibly) hundreds of bugs related to using both cache.xml and cluster configuration at

[Proposal]: behavior change when region doesn't exist in cluster configuration

Scenario: a locator with cluster configuration enabled and a server started with a cache.xml that has /regionA defined and connected to this locator. So the initial state is the locator has an empty cluster configuration for the cluster, but the server has a region defined in it's cache. Old