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 <sbawas...@pivotal.io> 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 <sai.boorlaga...@gmail.com> > 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 <jil...@pivotal.io> 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" <sai.boorlaga...@gmail.com> >>> 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 <jil...@pivotal.io> 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 < >>>>> sai.boorlaga...@gmail.com> 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 <dsm...@pivotal.io> 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 <jil...@pivotal.io> >>>>>>> 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
