Hi, Jason, I am able to start two servers using different cache.xml that each define a region with the same name but with different attribute. This might be because on one server, the region is defined as "local".
ServerA.xml <?xml version="1.0" encoding="UTF-8"?><cache xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xmlns=" http://geode.apache.org/schema/cache"; xsi:schemaLocation=" http://geode.apache.org/schema/cache http://geode.apache.org/schema/cache/cache-1.0.xsd"; version="1.0" is-server="true"> <cache-server/> <disk-store name="DEFAULT"/> <region name="regionA" refid="REPLICATE"> </region> <resource-manager eviction-heap-percentage="80"/> </cache> ServerB.xml <?xml version="1.0" encoding="UTF-8"?><cache xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xmlns=" http://geode.apache.org/schema/cache"; xsi:schemaLocation=" http://geode.apache.org/schema/cache http://geode.apache.org/schema/cache/cache-1.0.xsd"; version="1.0" is-server="true"> <cache-server/> <disk-store name="DEFAULT"/> <region name="regionA"> <region-attributes scope="local"> <eviction-attributes> <lru-heap-percentage action="local-destroy"/> </eviction-attributes> </region-attributes> </region> <resource-manager eviction-heap-percentage="80"/> </cache> On Fri, Apr 27, 2018 at 3:40 PM, Jason Huynh <jhu...@pivotal.io> wrote: > *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 <jhu...@pivotal.io> 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 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 partitioned region with the > same > > name (admittedly using the java api and not cluster config). So then if > > you run a gfsh command to create an index, it would only create the index > > on the first node and report back to cluster config the first nodes > > configuration and the new index. > > > > Going back to the original proposal, if the user ever wanted to have the > > cluster config updated with the region, how would they sync up their > > cluster config without bringing everything down? Sure they can export > xml > > and bring up another server with xml but that doesn't get them migrated > to > > cluster config... > > > > > > > > On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <jil...@pivotal.io> wrote: > > > >> 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 <n...@apache.org> wrote: > >> > >> > 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. > >> > > >> > So now when servers A and B start, they will have different regions > but > >> the > >> > same name “test”. Because there is no sync up with locator’s cluster > >> > config. > >> > > >> > Pardon me if my understanding is wrong. > >> > > >> > > >> > Regards > >> > Nabarun > >> > > >> > > >> > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <jil...@pivotal.io> > wrote: > >> > > >> > > 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 <jil...@pivotal.io> > >> 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 gfsh command > >> > > `create > >> > > > index` on that region, the command output would be something like: > >> > > > >create index ..... > >> > > > Member | Status > >> > > > ---------------------------- > >> > > > server-1 | Index successfully created. > >> > > > > >> > > > Cluster configuration for "cluster" is not updated > >> > > > Region XYZ does not exist in the cluster configuration (or > >> something to > >> > > > this effect). > >> > > > > >> > > > The command result would tell user exactly what happened and what > >> not > >> > > > happened. The point is, a server's own cache.xml is NOT meant to > be > >> a > >> > > > "cluster" wide configuration. If customer is in the habit of > >> starting > >> > up > >> > > > server with cache.xml but yet still want to have consistent > >> > region/index > >> > > > defined in the cluster, export a server's config and use that to > >> start > >> > > > another server. > >> > > > > >> > > > > >> > > > > >> > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman < > dhard...@pivotal.io > >> > > >> > > > wrote: > >> > > > > >> > > >> 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, throwing exceptions and logging errors when > region > >> > > >> definitions conflict (for the same region name) on different > >> servers > >> > in > >> > > >> the > >> > > >> same cluster. > >> > > >> We might then consider removing the cache.xml files and rely on > >> gfsh > >> > and > >> > > >> (in the future, hopefully) Java API's to keep cluster config > >> > up-to-date. > >> > > >> > >> > > >> Thanks! > >> > > >> > >> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <jil...@pivotal.io > > > >> > > wrote: > >> > > >> > >> > > >> > 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 server might have different opinion about what it is. > >> > > >> > > >> > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman < > >> > dhard...@pivotal.io> > >> > > >> > wrote: > >> > > >> > > >> > > >> > > 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 > >> > > before. > >> > > >> > > Is there something preventing you from checking cluster > config > >> > for a > >> > > >> > region > >> > > >> > > of the same name but different properties and, if so, > throwing > >> an > >> > > >> > exception > >> > > >> > > (or warning) > >> > > >> > > that cluster config could not be updated due to this > collision? > >> > > >> > > > >> > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz < > >> mst...@pivotal.io > >> > > > >> > > >> > wrote: > >> > > >> > > > >> > > >> > > > 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 <(631)%20835-4771> > >> > > >> > > > Download the GemFire book here. > >> > > >> > > > <https://content.pivotal.io/ebooks/scaling-data-services- > >> > > >> > > > with-pivotal-gemfire> > >> > > >> > > > > >> > > >> > > > On Thu, Apr 19, 2018 at 6:29 PM, Jinmei Liao < > >> jil...@pivotal.io > >> > > > >> > > >> > wrote: > >> > > >> > > > > >> > > >> > > > > 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 < > >> > > mst...@pivotal.io > >> > > >> > > >> > > >> > > > wrote: > >> > > >> > > > > > >> > > >> > > > > > 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 > >> > > the > >> > > >> > same > >> > > >> > > > > time. > >> > > >> > > > > > If we can make cluster config complete enough, and > >> deprecate > >> > > >> > > cache.xml, > >> > > >> > > > > > people will stop using cache.xml. > >> > > >> > > > > > > >> > > >> > > > > > > >> > > >> > > > > > > >> > > >> > > > > > -- > >> > > >> > > > > > Mike Stolz > >> > > >> > > > > > Principal Engineer, GemFire Product Lead > >> > > >> > > > > > Mobile: +1-631-835-4771 <(631)%20835-4771> > >> > > >> > > > > > Download the GemFire book here. > >> > > >> > > > > > < > >> https://content.pivotal.io/ebooks/scaling-data-services- > >> > > >> > > > > > with-pivotal-gemfire> > >> > > >> > > > > > > >> > > >> > > > > > On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao < > >> > > jil...@pivotal.io > >> > > >> > > >> > > >> > > > wrote: > >> > > >> > > > > > > >> > > >> > > > > > > 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 behavior: > >> > > >> > > > > > > when user execute "create index --region=/regionA > ...." > >> > > >> command > >> > > >> > > using > >> > > >> > > > > > gfsh, > >> > > >> > > > > > > the index creation is successful on the server, and > the > >> > > server > >> > > >> > > > returns > >> > > >> > > > > a > >> > > >> > > > > > > xml section that contains both <region> and <index> > >> > > elements, > >> > > >> CC > >> > > >> > is > >> > > >> > > > > > updated > >> > > >> > > > > > > with this xml, so the end result is: both region and > >> index > >> > > >> end up > >> > > >> > > in > >> > > >> > > > > the > >> > > >> > > > > > > cluster configuration. > >> > > >> > > > > > > > >> > > >> > > > > > > Problem with old behavior: > >> > > >> > > > > > > Not sure if the region is a cluster wide > configuration. > >> > What > >> > > >> if a > >> > > >> > > > > region > >> > > >> > > > > > > with the same name, but different type exists on > >> different > >> > > >> > servers? > >> > > >> > > > the > >> > > >> > > > > > xml > >> > > >> > > > > > > returned by different server might be different. > >> > > >> > > > > > > > >> > > >> > > > > > > New behavior: > >> > > >> > > > > > > when user execute "create index --region=/regionA > ...." > >> > > >> command > >> > > >> > > using > >> > > >> > > > > > gfsh, > >> > > >> > > > > > > the index creation is successful on the server. We > >> failed > >> > to > >> > > >> find > >> > > >> > > the > >> > > >> > > > > > > region in the existing cluster configuration, so > >> cluster > >> > > >> > > > configuration > >> > > >> > > > > > will > >> > > >> > > > > > > NOT be updated. > >> > > >> > > > > > > > >> > > >> > > > > > > I would also suggest that this would not apply to > index > >> > > alone, > >> > > >> > any > >> > > >> > > > > > element > >> > > >> > > > > > > inside region would have the same behavior change if > we > >> > > >> approve > >> > > >> > > this. > >> > > >> > > > > > > > >> > > >> > > > > > > Thanks! > >> > > >> > > > > > > > >> > > >> > > > > > > -- > >> > > >> > > > > > > Cheers > >> > > >> > > > > > > > >> > > >> > > > > > > Jinmei > >> > > >> > > > > > > > >> > > >> > > > > > > >> > > >> > > > > > >> > > >> > > > > > >> > > >> > > > > > >> > > >> > > > > -- > >> > > >> > > > > Cheers > >> > > >> > > > > > >> > > >> > > > > Jinmei > >> > > >> > > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > -- > >> > > >> > Cheers > >> > > >> > > >> > > >> > Jinmei > >> > > >> > > >> > > >> > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Cheers > >> > > > > >> > > > Jinmei > >> > > > > >> > > > >> > > > >> > > > >> > > -- > >> > > Cheers > >> > > > >> > > Jinmei > >> > > > >> > > >> > >> > >> > >> -- > >> Cheers > >> > >> Jinmei > >> > > > -- Cheers Jinmei
