If you're only enforcing it at the gfsh or admin api level I guess that
would still be ok. Yep, I think you have the right rules then.

--
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:05 AM, Michael Stolz <mst...@pivotal.io> wrote:

> 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 <(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 11:03 AM, Jinmei Liao <jil...@pivotal.io> 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 <mst...@pivotal.io> 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 <jil...@pivotal.io> 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 <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
>>>>
>>>
>>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
>
>

Reply via email to