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 >
