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 <jb...@pivotal.io> wrote: > Hi Jinmei- > > Regarding this... > > " > > *So the current behavior is, when a customer starts a server with > cache.xmlthat has a region defined, and then later on issues a gfsh command > `createindex` 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 updatedRegion XYZ does > not exist in the cluster configuration (or something tothis effect).*" > > I don't think the Cluster Config should be updated in this case (which I > guess is consistent with the new behavior, which I thought was also the old > behavior, but anyway...) > > cache.xml, like *Spring* config, like using the Geode public API to > configure/change (e.g. using *AttributesMutator* to add a custom/node > specific *CacheListener/Loader* or *Writer*, perhaps) the node's > configuration is an "augmenting" behavior. > > Also, a Region's "configuration", whether that be the DataPolicy or several > other factors, cannot differ between different nodes in the cluster also > hosting the same Region, by "name", (especially if that is a PARTITION > Region. > > -j > > > > 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 > > >> > > > > > > > > > -- > -John > john.blum10101 (skype) > -- Cheers Jinmei
