Seems like you don't want the second one. Proxy should be allowed, yes? -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the new GemFire book here. <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire>
On Tue, Feb 6, 2018 at 10:56 AM, Jinmei Liao <[email protected]> wrote: > Based on these feedback, could we do this instead? > > 1. creating non-proxy region: check to see if there is a non-proxy region > with the same name on the entire cluster or not. If yes, abort the creation. > 2. creating proxy region: check to see if there is any region with the > same name on the group or not, if yes, abort the creation. > > I think this would catch all cases. > > > > On Sat, Feb 3, 2018 at 12:01 AM, Swapnil Bawaskar <[email protected]> > wrote: > >> Sometimes PROXY regions are used just to pass messages between members. >> In this use case, there are no regions that store data. Point 2 will break >> this use case. >> >> On Fri, Feb 2, 2018 at 2:22 PM Sai Boorlagadda <[email protected]> >> wrote: >> >>> +1 to the proposal with the modified rule and favoring region creation >>> with shortcuts. >>> >>> On Fri, Feb 2, 2018 at 1:56 PM, Jinmei Liao <[email protected]> wrote: >>> >>>> I think we allowed too many ways for the user to do the same thing >>>> again. >>>> >>>> if we put in this restriction, this command would fail and user has to >>>> use PARTITION_PROXY type to create an accessor region, which is not a bad >>>> thing after all. >>>> >>>> So now, the rule is: >>>> >>>> 1. when user creates a non-proxy region (no matter on what group, what >>>> type), a region with the same name can not exist already in the cluster >>>> 2. When user creates a proxy region, a region with the same name has to >>>> exist on the cluster first. >>>> >>>> would this be a reasonable rule to enforce when creating regions using >>>> gfsh? >>>> >>>> >>>> On Feb 2, 2018 12:02 PM, "Sai Boorlagadda" <[email protected]> >>>> wrote: >>>> >>>>> I dont think allowing *_PROXY types with same names is sufficient. >>>>> Users can also create accessor regions by setting 'local-max-memory' for a >>>>> partition region (though not allowed for a replicate). >>>>> >>>>> gfsh>create region --name=test --type=PARTITION --local-max-memory=0 >>>>> Member | Status >>>>> --------------- | ------------------------------------------ >>>>> yell-gifted-cow | Region "/test" created on "server1" >>>>> >>>>> Here /test becomes an accessor region just like when created using the >>>>> shortcut "PARTITION_PROXY". >>>>> >>>>> On Fri, Feb 2, 2018 at 11:46 AM, Jinmei Liao <[email protected]> >>>>> wrote: >>>>> >>>>>> Accessor region is probably a special case. Then can we add this >>>>>> caviar then: "user can not create a region with the same name of a >>>>>> different type except it's a proxy region"? >>>>>> >>>>>> On Fri, Feb 2, 2018 at 11:17 AM, Sai Boorlagadda < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Agree with Dan. This is the only way I know that you can create >>>>>>> accessor regions on peer members. >>>>>>> >>>>>>> On Fri, Feb 2, 2018 at 11:07 AM, Dan Smith <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Won't this break any use case were two members need to create the >>>>>>>> same region with different attributes? For example someone might have >>>>>>>> some >>>>>>>> members that are empty accessors of a replicated region: >>>>>>>> >>>>>>>> //Host data on members in group1 >>>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group1 >>>>>>>> >>>>>>>> //Group2 just needs access to data in region A >>>>>>>> gfsh> create region --name=A --type=REPLICATE_PROXY --group=group2 >>>>>>>> >>>>>>>> -Dan >>>>>>>> >>>>>>>> On Fri, Feb 2, 2018 at 10:19 AM, Jinmei Liao <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Currently creating region with the same name on different groups >>>>>>>>> are allowed by gfsh. Checks are done further on the servers when >>>>>>>>> creating >>>>>>>>> the region to see if the region attributes clashes with any existing >>>>>>>>> region, and the operation will fail if types are different. Here is an >>>>>>>>> example about this current behavior: >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group1 // >>>>>>>>> success >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group2 // >>>>>>>>> success >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=PARTITION --group=group2 >>>>>>>>> --skip-if-exists // skipping >>>>>>>>> >>>>>>>>> Member | Status >>>>>>>>> >>>>>>>>> ------- | ----------------------------------------------- >>>>>>>>> >>>>>>>>> server2 | Skipping "server2". Region "/A" already exists. >>>>>>>>> >>>>>>>>> >>>>>>>>> gfsh>create region --name=A --type=PARTITION --group=group3 >>>>>>>>> --skip-if-exists // failure >>>>>>>>> >>>>>>>>> Member | Status >>>>>>>>> >>>>>>>>> ------- | ------------------------------ >>>>>>>>> ------------------------------------------------------------ >>>>>>>>> ------------------------------------------------------------ >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> server3 | ERROR: Cannot create PartitionedRegion /A because >>>>>>>>> another cache (10.118.33.243(server2:43156)<v4>:1026) has the >>>>>>>>> same region defined as a non PartitionedRegion. >>>>>>>>> >>>>>>>>> We would like to propose catching the name clash earlier in gfsh >>>>>>>>> for the last command as well. Since regions are referred to by names >>>>>>>>> in the >>>>>>>>> entire cluster (no server grouping considered at all), when trying to >>>>>>>>> create a region, we should check for name clash in the entire >>>>>>>>> cluster, not >>>>>>>>> just in the specified server group. If we make this change, the >>>>>>>>> behavior >>>>>>>>> would be like this: >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group1 // >>>>>>>>> success >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group2 // >>>>>>>>> Error >>>>>>>>> >>>>>>>>> ERROR: Region "/A" already exists. >>>>>>>>> >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=REPLICATE --group=group2 >>>>>>>>> --skip-if-exists // skipping >>>>>>>>> >>>>>>>>> Skipping: Region "/A" already exists. >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=PARTITION --group=group2 >>>>>>>>> --skip-if-exists >>>>>>>>> >>>>>>>>> Skipping. Region "/A" already exists. >>>>>>>>> >>>>>>>>> gfsh> create region --name=A --type=PARTITION --group=group3 >>>>>>>>> --skip-if-exists >>>>>>>>> Skipping. Region "/A" already exists. >>>>>>>>> >>>>>>>>> >>>>>>>>> Basically, the name clash check is on the entire cluster, not just >>>>>>>>> on one specific server. This would lead to some change in script >>>>>>>>> behavior, >>>>>>>>> but keep the command simple and consistent. >>>>>>>>> >>>>>>>>> Any feedback is welcome. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> >>>>>>>>> Jinmei >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers >>>>>> >>>>>> Jinmei >>>>>> >>>>> >>>>> >>> > > > -- > Cheers > > Jinmei >
