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
>

Reply via email to