Ah, on the same member. That makes sense. What if it is a new member joining the group?
-- 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 11:03 AM, Jinmei Liao <[email protected]> wrote: > I do want the second one. Proxy region should be allowed only if it's on a > different member (as far as I gather from the discussion). If I am trying > to create a proxy region on serve1, but server1 already has a REPLICATE > region with the same name, I should abort the creation. > > On Tue, Feb 6, 2018 at 8:00 AM, Michael Stolz <[email protected]> wrote: > >> 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 <(631)%20835-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 >>> >> >> > > > -- > Cheers > > Jinmei >
