[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors
[ https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872907#comment-15872907 ] huzheng commented on HBASE-17312: - Hi [~appy] [~zghaobac] is on vacation this days, so go ahead. :) > [JDK8] Use default method for Observer Coprocessors > --- > > Key: HBASE-17312 > URL: https://issues.apache.org/jira/browse/HBASE-17312 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 2.0.0 >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17312.master.001.patch, > HBASE-17312.master.001.patch > > > Use default method in MasterObserver, RegionObserver, RegionServerObserver > and WALObserver. And mark the BaseRegionObserver, > BaseMasterAndRegionObserver, BaseRegionServerObserver and BaseWALObserver. > User can implement the interface directly and will not break compatibility > when add new default methods. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872896#comment-15872896
]
huzheng commented on HBASE-17472:
-
Any concerns ? [~Apache9]], [~enis], [~busbey], Thanks.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.branch-1.v7.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.master.v7.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872896#comment-15872896
]
huzheng edited comment on HBASE-17472 at 2/18/17 2:09 AM:
--
Any concerns ? [~Apache9], [~enis], [~busbey], Thanks.
was (Author: openinx):
Any concerns ? [~Apache9]], [~enis], [~busbey], Thanks.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.branch-1.v7.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.master.v7.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17646) Implement Async getRegion method
[ https://issues.apache.org/jira/browse/HBASE-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17646: Attachment: HBASE-17646.v1.patch > Implement Async getRegion method > > > Key: HBASE-17646 > URL: https://issues.apache.org/jira/browse/HBASE-17646 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17646.v1.patch, HBASE-17646.v1.patch > > > There are some async admin APIs which depends on async getRegion method. > Such as : > 1. closeRegion. > 2. flushRegion. > 3. compactRegion. > 4. mergeRegion. > 5. splitRegion. > and so on . > So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871148#comment-15871148
]
huzheng commented on HBASE-17472:
-
Upload patch v7 for removing all grant2.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.branch-1.v7.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.master.v7.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.master.v7.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.branch-1.v7.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.master.v7.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.branch-1.v7.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.branch-1.v7.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.v1.patch, HBASE-17472.v2.patch, HBASE-17472.v3.patch,
> HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15871070#comment-15871070
]
huzheng commented on HBASE-17472:
-
Oh... Sorry, Will upload a new patch. Thanks [~enis]
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870108#comment-15870108
]
huzheng commented on HBASE-17472:
-
[~Apache9], Thanks for reminding . Upload patch for branch-1, the previous
one is for branch-1.3 and it may apply failed.
> And huzheng, you need to take care of the shell command. If we also want to
> introduce a flag for the grant command in shell, you need to find a proper to
> do it as the default behavior on master and branch-1 are different.
OK
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.v1.patch, HBASE-17472.v2.patch, HBASE-17472.v3.patch,
> HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.branch-1.v6.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0, 1.4.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.branch-1.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17651) Add a flag for grant ruby shell command to merge existing permissions.
[ https://issues.apache.org/jira/browse/HBASE-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869710#comment-15869710 ] huzheng commented on HBASE-17651: - Will upload a patch as [~busbey] said. > Add a flag for grant ruby shell command to merge existing permissions. > -- > > Key: HBASE-17651 > URL: https://issues.apache.org/jira/browse/HBASE-17651 > Project: HBase > Issue Type: Sub-task > Components: Admin >Reporter: huzheng >Assignee: huzheng > Labels: shell > Fix For: 1.3.0 > > > As HBASE-17472 said, we'll implement a new shell command grant2 to add one > or more action(s) for user, and deprecated previous grant shell command. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17651) Add a flag for grant ruby shell command to merge existing permissions.
[ https://issues.apache.org/jira/browse/HBASE-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17651: Summary: Add a flag for grant ruby shell command to merge existing permissions. (was: Implement grant2 ruby shell command.) > Add a flag for grant ruby shell command to merge existing permissions. > -- > > Key: HBASE-17651 > URL: https://issues.apache.org/jira/browse/HBASE-17651 > Project: HBase > Issue Type: Sub-task > Components: Admin >Reporter: huzheng >Assignee: huzheng > Labels: shell > Fix For: 1.3.0 > > > As HBASE-17472 said, we'll implement a new shell command grant2 to add one > or more action(s) for user, and deprecated previous grant shell command. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17651) Implement grant2 ruby shell command.
[ https://issues.apache.org/jira/browse/HBASE-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17651: Fix Version/s: (was: 2.0.0) 1.3.0 > Implement grant2 ruby shell command. > > > Key: HBASE-17651 > URL: https://issues.apache.org/jira/browse/HBASE-17651 > Project: HBase > Issue Type: Sub-task > Components: Admin >Reporter: huzheng >Assignee: huzheng > Labels: shell > Fix For: 1.3.0 > > > As HBASE-17472 said, we'll implement a new shell command grant2 to add one > or more action(s) for user, and deprecated previous grant shell command. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869707#comment-15869707
]
huzheng commented on HBASE-17472:
-
Upload patch for branch-1.3: Provide a extra grant(...,
mergeExistingPermissions) rpc api for user, and grant(...) behavior the
same as before.
After that, I'll add a flag in grant ruby shell command for branch-1.3 to
invoke grant(..., mergeExstingPermissions). patch will be uploaded under
HBASE-17651.
[~busbey], Thanks for your advise.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.v1.patch, HBASE-17472.v2.patch, HBASE-17472.v3.patch,
> HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.branch-1.3.v6.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.branch-1.3.v6.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.master.v6.patch,
> HBASE-17472.v1.patch, HBASE-17472.v2.patch, HBASE-17472.v3.patch,
> HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.master.v6.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.master.v6.patch,
> HBASE-17472.master.v6.patch, HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869415#comment-15869415
]
huzheng commented on HBASE-17472:
-
Patch for branch-1 will be different, I'll upload it later.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.master.v6.patch, HBASE-17472.v1.patch,
> HBASE-17472.v2.patch, HBASE-17472.v3.patch, HBASE-17472.v4.patch,
> HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869412#comment-15869412
]
huzheng commented on HBASE-17472:
-
Upload patch v6 for master branch :
1. remove grant2 method in AccessControllerClient, and just keep grant method
(merge behavior) for RpcUser.
2. adjust ut.
For master branch, ruby shell command need no modification.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.master.v6.patch, HBASE-17472.v1.patch,
> HBASE-17472.v2.patch, HBASE-17472.v3.patch, HBASE-17472.v4.patch,
> HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.master.v6.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.master.v6.patch, HBASE-17472.v1.patch,
> HBASE-17472.v2.patch, HBASE-17472.v3.patch, HBASE-17472.v4.patch,
> HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15868996#comment-15868996
]
huzheng commented on HBASE-17472:
-
Thanks [~busbey], [~enis], [~Apache9], new patch with a flag will come soon.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867954#comment-15867954 ] huzheng commented on HBASE-17619: - Upload patch v2: 1. remove useless final modifier in AsyncAdmin interface. 2. Add TODO, to abstract call & adminCall into a single one. 3. use default timeout for closeRegion test case. > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch, HBASE-17619.v1.patch, > HBASE-17619.v2.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17619: Attachment: HBASE-17619.v2.patch > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch, HBASE-17619.v1.patch, > HBASE-17619.v2.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867884#comment-15867884
]
huzheng commented on HBASE-17472:
-
Hi [~Apache9], I've created HBASE-17651 for it.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17651) Implement grant2 ruby shell command.
huzheng created HBASE-17651: --- Summary: Implement grant2 ruby shell command. Key: HBASE-17651 URL: https://issues.apache.org/jira/browse/HBASE-17651 Project: HBase Issue Type: Sub-task Components: Admin Reporter: huzheng Assignee: huzheng Fix For: 2.0.0 As HBASE-17472 said, we'll implement a new shell command grant2 to add one or more action(s) for user, and deprecated previous grant shell command. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-17646) Implement Async getRegion method
[ https://issues.apache.org/jira/browse/HBASE-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867801#comment-15867801 ] huzheng edited comment on HBASE-17646 at 2/15/17 1:19 PM: -- Upload patch v1. And this patch depends on HBASE-17619, so I will put it to ReviewBoard after HBASE-17619 committed to hbase-git. was (Author: openinx): Upload patch v1. > Implement Async getRegion method > > > Key: HBASE-17646 > URL: https://issues.apache.org/jira/browse/HBASE-17646 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17646.v1.patch > > > There are some async admin APIs which depends on async getRegion method. > Such as : > 1. closeRegion. > 2. flushRegion. > 3. compactRegion. > 4. mergeRegion. > 5. splitRegion. > and so on . > So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17646) Implement Async getRegion method
[ https://issues.apache.org/jira/browse/HBASE-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17646: Status: Patch Available (was: Open) > Implement Async getRegion method > > > Key: HBASE-17646 > URL: https://issues.apache.org/jira/browse/HBASE-17646 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17646.v1.patch > > > There are some async admin APIs which depends on async getRegion method. > Such as : > 1. closeRegion. > 2. flushRegion. > 3. compactRegion. > 4. mergeRegion. > 5. splitRegion. > and so on . > So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17646) Implement Async getRegion method
[ https://issues.apache.org/jira/browse/HBASE-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867801#comment-15867801 ] huzheng commented on HBASE-17646: - Upload patch v1. > Implement Async getRegion method > > > Key: HBASE-17646 > URL: https://issues.apache.org/jira/browse/HBASE-17646 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17646.v1.patch > > > There are some async admin APIs which depends on async getRegion method. > Such as : > 1. closeRegion. > 2. flushRegion. > 3. compactRegion. > 4. mergeRegion. > 5. splitRegion. > and so on . > So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17646) Implement Async getRegion method
[ https://issues.apache.org/jira/browse/HBASE-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17646: Attachment: HBASE-17646.v1.patch > Implement Async getRegion method > > > Key: HBASE-17646 > URL: https://issues.apache.org/jira/browse/HBASE-17646 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17646.v1.patch > > > There are some async admin APIs which depends on async getRegion method. > Such as : > 1. closeRegion. > 2. flushRegion. > 3. compactRegion. > 4. mergeRegion. > 5. splitRegion. > and so on . > So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867469#comment-15867469
]
huzheng edited comment on HBASE-17472 at 2/15/17 8:43 AM:
--
Upload patch v5.
1. set default value to false for new protobuf field
(mergeExistingPermissions);
2. using LOG.error(message, t) to print grant(2)/revoke exception , instead of
e.printStraceTrace().
was (Author: openinx):
Upload patch v5.
1. set default value to false for new fields (mergeExistingPermissions);
2. using LOG.error(message, t) to print grant(2)/revoke exception , instead of
e.printStraceTrace().
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867469#comment-15867469
]
huzheng commented on HBASE-17472:
-
Upload patch v5.
1. set default value to false for new fields (mergeExistingPermissions);
2. using LOG.error(message, t) to print grant(2)/revoke exception , instead of
e.printStraceTrace().
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.v5.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch, HBASE-17472.v5.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15867173#comment-15867173
]
huzheng commented on HBASE-17472:
-
Upload patch v4.According to review comments, patch v4 remove
unnecessary commented RpcController code, and refactor
shouldMergeExistPermissions to mergeExistingPermissions.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.v4.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch, HBASE-17472.v4.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865797#comment-15865797 ] huzheng commented on HBASE-17619: - Add review link : https://reviews.apache.org/r/56662/ > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch, HBASE-17619.v1.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17619: Comment: was deleted (was: [~Apache9], upload ruby patch for HBASE-17472 ? Yeah , I left a comment under HBASE-17472 , and if Java Patch is OK , I'll create another sub-task to add grant2 ruby command. ) > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch, HBASE-17619.v1.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865782#comment-15865782
]
huzheng commented on HBASE-17472:
-
Thanks [~Apache9], I will upload a new patch for your review comment.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865776#comment-15865776 ] huzheng commented on HBASE-17619: - [~Apache9], upload ruby patch for HBASE-17472 ? Yeah , I left a comment under HBASE-17472 , and if Java Patch is OK , I'll create another sub-task to add grant2 ruby command. > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch, HBASE-17619.v1.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17645) Improve the connection usage in PE tool
[ https://issues.apache.org/jira/browse/HBASE-17645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865478#comment-15865478 ] huzheng commented on HBASE-17645: - So , if oneCon flag is false. we could just pass a null Connection object , instead of a created Connection ? > Improve the connection usage in PE tool > --- > > Key: HBASE-17645 > URL: https://issues.apache.org/jira/browse/HBASE-17645 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > > In PE tool we have the option of using one connection for all threads. By > default it is false. And you can see a big difference in the measurements > that the tool produces and also the load that it generates on the server side > when this oneCon is false/true. > Also if you see if oneCon is false, we still create one connection for > initilaizing the threads and again that connection is overwritten when the > threads actually starts running by creating a connection. I think we can do > some clean up here. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17646) Implement Async getRegion method
[ https://issues.apache.org/jira/browse/HBASE-17646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17646: Issue Type: Sub-task (was: Bug) Parent: HBASE-17359 > Implement Async getRegion method > > > Key: HBASE-17646 > URL: https://issues.apache.org/jira/browse/HBASE-17646 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > > There are some async admin APIs which depends on async getRegion method. > Such as : > 1. closeRegion. > 2. flushRegion. > 3. compactRegion. > 4. mergeRegion. > 5. splitRegion. > and so on . > So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17646) Implement Async getRegion method
huzheng created HBASE-17646: --- Summary: Implement Async getRegion method Key: HBASE-17646 URL: https://issues.apache.org/jira/browse/HBASE-17646 Project: HBase Issue Type: Bug Components: asyncclient Affects Versions: 2.0.0 Reporter: huzheng Assignee: huzheng Fix For: 2.0.0 There are some async admin APIs which depends on async getRegion method. Such as : 1. closeRegion. 2. flushRegion. 3. compactRegion. 4. mergeRegion. 5. splitRegion. and so on . So, implement async getRegion method first. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865132#comment-15865132
]
huzheng commented on HBASE-17472:
-
[~ashish singhi], [~Apache9], [~zghaobac] Could you help to review the patch
v3 ?
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17619: Attachment: HBASE-17619.v1.patch > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch, HBASE-17619.v1.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17619: Status: Patch Available (was: Open) > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17619: Attachment: HBASE-17619.v1.patch > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > Attachments: HBASE-17619.v1.patch > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[ https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864918#comment-15864918 ] huzheng commented on HBASE-17619: - So , I'll upload a patch , which implement other 3 API. After that, I'll create a subtask to implement AsyncAdmin.getRegion API. > Add async admin Impl which connect to RegionServer and implement close region > methods. > -- > > Key: HBASE-17619 > URL: https://issues.apache.org/jira/browse/HBASE-17619 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Affects Versions: 2.0.0 >Reporter: huzheng >Assignee: huzheng > Labels: asynchronous > Fix For: 2.0.0 > > > Currently , Async client has async master impl and async htable impl , but > not async admin impl , which connect to RS for managing regions in region > server . > This issue will add async admin which implement AdminService.Interface to > AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
[
https://issues.apache.org/jira/browse/HBASE-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864913#comment-15864913
]
huzheng commented on HBASE-17619:
-
Currently, we have 4 closeRegion API:
{code}
CompletableFuture closeRegion(final String regionname, final String
serverName);
CompletableFuture closeRegion(final byte[] regionname, final String
serverName);
CompletableFuture closeRegionWithEncodedRegionName(final String
encodedRegionName, final String serverName);
CompletableFuture closeRegion(final ServerName sn, final HRegionInfo hri);
{code}
And there's some special for implementing
{code}CompletableFuture closeRegion(final byte[] regionname, final String
serverName){code} ,
because this API allow serverName to be null , and need to get RegionServer by
regionname, which depends on AsyncAdmin.getRegion API implementation.
> Add async admin Impl which connect to RegionServer and implement close region
> methods.
> --
>
> Key: HBASE-17619
> URL: https://issues.apache.org/jira/browse/HBASE-17619
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Labels: asynchronous
> Fix For: 2.0.0
>
>
> Currently , Async client has async master impl and async htable impl , but
> not async admin impl , which connect to RS for managing regions in region
> server .
> This issue will add async admin which implement AdminService.Interface to
> AsyncConnectionImpl, and implement close region method.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17619) Add async admin Impl which connect to RegionServer and implement close region methods.
huzheng created HBASE-17619: --- Summary: Add async admin Impl which connect to RegionServer and implement close region methods. Key: HBASE-17619 URL: https://issues.apache.org/jira/browse/HBASE-17619 Project: HBase Issue Type: Sub-task Components: asyncclient Affects Versions: 2.0.0 Reporter: huzheng Assignee: huzheng Fix For: 2.0.0 Currently , Async client has async master impl and async htable impl , but not async admin impl , which connect to RS for managing regions in region server . This issue will add async admin which implement AdminService.Interface to AsyncConnectionImpl, and implement close region method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17359) Implement async admin
[ https://issues.apache.org/jira/browse/HBASE-17359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857785#comment-15857785 ] huzheng commented on HBASE-17359: - I will take the charge of Region Admin Operations. :) > Implement async admin > - > > Key: HBASE-17359 > URL: https://issues.apache.org/jira/browse/HBASE-17359 > Project: HBase > Issue Type: Umbrella > Components: Client >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Labels: asynchronous > Fix For: 2.0.0 > > > And as we will return a CompletableFuture, I think we can just remove the > XXXAsync methods, and make all the methods blocking which means we will only > finish the CompletableFuture when the operation is done. User can choose > whether to wait on the returned CompletableFuture. > Convert this to a umbrella task. There maybe some sub-tasks. > 1. Table admin operations. > 2. Region admin operations. > 3. Namespace admin operations. > 4. Snapshot admin operations. > 5. Replication admin operations. > 6. Other operations, like quota, balance.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17359) Implement async admin
[ https://issues.apache.org/jira/browse/HBASE-17359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857783#comment-15857783 ] huzheng commented on HBASE-17359: - Could I take the charge of Region Admin Operations ? > Implement async admin > - > > Key: HBASE-17359 > URL: https://issues.apache.org/jira/browse/HBASE-17359 > Project: HBase > Issue Type: Umbrella > Components: Client >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Labels: asynchronous > Fix For: 2.0.0 > > > And as we will return a CompletableFuture, I think we can just remove the > XXXAsync methods, and make all the methods blocking which means we will only > finish the CompletableFuture when the operation is done. User can choose > whether to wait on the returned CompletableFuture. > Convert this to a umbrella task. There maybe some sub-tasks. > 1. Table admin operations. > 2. Region admin operations. > 3. Namespace admin operations. > 4. Snapshot admin operations. > 5. Replication admin operations. > 6. Other operations, like quota, balance.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Issue Comment Deleted] (HBASE-17359) Implement async admin
[ https://issues.apache.org/jira/browse/HBASE-17359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-17359: Comment: was deleted (was: Could I take the charge of Region Admin Operations ? ) > Implement async admin > - > > Key: HBASE-17359 > URL: https://issues.apache.org/jira/browse/HBASE-17359 > Project: HBase > Issue Type: Umbrella > Components: Client >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Labels: asynchronous > Fix For: 2.0.0 > > > And as we will return a CompletableFuture, I think we can just remove the > XXXAsync methods, and make all the methods blocking which means we will only > finish the CompletableFuture when the operation is done. User can choose > whether to wait on the returned CompletableFuture. > Convert this to a umbrella task. There maybe some sub-tasks. > 1. Table admin operations. > 2. Region admin operations. > 3. Namespace admin operations. > 4. Snapshot admin operations. > 5. Replication admin operations. > 6. Other operations, like quota, balance.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857431#comment-15857431
]
huzheng commented on HBASE-17381:
-
Failed UT(testRegionServerCoprocessorsReported) in Jenkins works fine under my
desktop machine. And there are no useful log to debug in jenkins. :(
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5
>
> Attachments: HBASE-17381.patch, HBASE-17381.v1.patch,
> HBASE-17381.v2.patch, HBASE-17381.v3.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Affects Version/s: 2.0.0
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857355#comment-15857355
]
huzheng commented on HBASE-17472:
-
Upload patch v3:
1. add java docs for grant/grant2 API.
2. fix failed UT TestTablePermissions. which caused by using a TreeSet to
serialize multiple enum variables into byte array. So I reorder the expected
array for AssertEquals , and UT pass.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.v3.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch,
> HBASE-17472.v3.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857303#comment-15857303
]
huzheng commented on HBASE-17381:
-
Thanks for your help, [~ghelmling]
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5
>
> Attachments: HBASE-17381.patch, HBASE-17381.v1.patch,
> HBASE-17381.v2.patch, HBASE-17381.v3.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855994#comment-15855994
]
huzheng commented on HBASE-17472:
-
Upload patch v2, which remove unnecessary modifications.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.v2.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch, HBASE-17472.v2.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855965#comment-15855965
]
huzheng commented on HBASE-17381:
-
[~apurtell] , [~ghelmling] , Could you help me to review patch v3 ? Thanks .
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Attachments: HBASE-17381.patch, HBASE-17381.v1.patch,
> HBASE-17381.v2.patch, HBASE-17381.v3.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Fix Version/s: 2.0.0
Status: Patch Available (was: Open)
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17472.v1.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15855954#comment-15855954
]
huzheng commented on HBASE-17472:
-
I've uploaded a patch v1 , which implement a new RPC API named grant2 and
deprecate grant RPC API . The grant2 rpc API can add one or more action(s)
for a user .
Later, I'll create another issue to add a new ruby shell command : grant2.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Attachments: HBASE-17472.v1.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Attachment: HBASE-17472.v1.patch
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
> Attachments: HBASE-17472.v1.patch
>
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853467#comment-15853467
]
huzheng commented on HBASE-17381:
-
[~apurtell] , [~ghelmling] , Really thanks for your advise . So dev team
favor aborting for unhandled exceptions.
I upload patch v3
(https://issues.apache.org/jira/secure/attachment/12851104/HBASE-17381.v3.patch)
for it .
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Attachments: HBASE-17381.patch, HBASE-17381.v1.patch,
> HBASE-17381.v2.patch, HBASE-17381.v3.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17381:
Attachment: HBASE-17381.v3.patch
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Attachments: HBASE-17381.patch, HBASE-17381.v1.patch,
> HBASE-17381.v2.patch, HBASE-17381.v3.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15823708#comment-15823708
]
huzheng commented on HBASE-17472:
-
[~Apache9][~ashish singhi] [~Weizhan Zeng] thanks for your advise, I'll upload
a patch :)
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15823543#comment-15823543
]
huzheng commented on HBASE-17472:
-
[~ashish singhi] , Your concern is reasonable . Can we add hint for grant
command after we change the behavior ?
On the side, currently, we can't revoke single action of a user ,
administrators maybe use grant command to revoke single action for a user , I
guess.
So , a more reasonable solution ( behavior like other databases , such as
MySQL) maybe :
1. Grant command add (not replace) one or more action(s) for a user;
2. Revoke command remove one or more action(s) for a user.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
> hbase_tst default,ycsb,,:
> [Permission: actions=CREATE,ADMIN]
>
>
> 1 row(s) in 0.0490 seconds
> {code}
> Later permission will replace previous granted permissions, which confused
> most of HBase administrator.
> It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Description:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
1 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, which confused most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
was:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
1 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, It seems confuse
most of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Description:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
1 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, It seems confuse
most of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
was:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, which confused most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 1 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Description:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, which confused most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
was:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, Which confused most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 4 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Description:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, Which confused most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
was:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, It seems confuse
most of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 4 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission
[jira] [Updated] (HBASE-17472) Correct the semantic of permission grant
[
https://issues.apache.org/jira/browse/HBASE-17472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17472:
Description:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions, It seems confuse
most of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
was:
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions seems confuse most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
> Correct the semantic of permission grant
> -
>
> Key: HBASE-17472
> URL: https://issues.apache.org/jira/browse/HBASE-17472
> Project: HBase
> Issue Type: Improvement
> Components: Admin
>Reporter: huzheng
>Assignee: huzheng
>
> Currently, HBase grant operation has following semantic:
> {code}
> hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
> 0 row(s) in 0.0960 seconds
> hbase(main):020:0> user_permission 'ycsb'
> User
> Namespace,Table,Family,Qualifier:Permission
>
>
>
> hbase_tst default,ycsb,,:
> [Permission:actions=READ,WRITE]
>
>
> 4 row(s) in 0.0550 seconds
> hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
> 0 row(s) in 0.0820 seconds
> hbase(main):022:0> user_permission
[jira] [Created] (HBASE-17472) Correct the semantic of permission grant
huzheng created HBASE-17472:
---
Summary: Correct the semantic of permission grant
Key: HBASE-17472
URL: https://issues.apache.org/jira/browse/HBASE-17472
Project: HBase
Issue Type: Improvement
Components: Admin
Reporter: huzheng
Assignee: huzheng
Currently, HBase grant operation has following semantic:
{code}
hbase(main):019:0> grant 'hbase_tst', 'RW', 'ycsb'
0 row(s) in 0.0960 seconds
hbase(main):020:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission:actions=READ,WRITE]
4 row(s) in 0.0550 seconds
hbase(main):021:0> grant 'hbase_tst', 'CA', 'ycsb'
0 row(s) in 0.0820 seconds
hbase(main):022:0> user_permission 'ycsb'
User
Namespace,Table,Family,Qualifier:Permission
hbase_tst default,ycsb,,:
[Permission: actions=CREATE,ADMIN]
1 row(s) in 0.0490 seconds
{code}
Later permission will replace previous granted permissions seems confuse most
of HBase administrator.
It's seems more reasonable that HBase merge multiple granted permission.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17450) TablePermission#equals throws NPE after namespace support was added
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15823369#comment-15823369
]
huzheng commented on HBASE-17450:
-
Thanks, Ted.
> TablePermission#equals throws NPE after namespace support was added
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17450.v1.patch
>
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17450:
Status: Patch Available (was: Open)
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
> Attachments: HBASE-17450.v1.patch
>
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821572#comment-15821572
]
huzheng commented on HBASE-17450:
-
I uploaded a patch for fix TablePermission.equals() first.
readFields() or writeFields() fix seems break compatibility :(
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
> Attachments: HBASE-17450.v1.patch
>
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17450:
Attachment: HBASE-17450.v1.patch
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
> Attachments: HBASE-17450.v1.patch
>
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15817897#comment-15817897
]
huzheng edited comment on HBASE-17450 at 1/11/17 10:18 AM:
---
Except equals() method, others method (such as readFields(), write() , ...
)will throw NPE also .
I will upload a patch for them.
was (Author: openinx):
Except equals() method, others method (such as readFields(), write() , ...
)will throw NPE also .
I will upload a patch for them.
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15817897#comment-15817897
]
huzheng edited comment on HBASE-17450 at 1/11/17 10:17 AM:
---
Except equals() method, others method (such as readFields(), write() , ...
)will throw NPE also .
I will upload a patch for them.
was (Author: openinx):
Except equals() method, others method (such as readFields(), write() , ...
)will throw NPE also .
Should we fix them ?
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15817897#comment-15817897
]
huzheng commented on HBASE-17450:
-
Except equals() method, others method (such as readFields(), write() , ...
)will throw NPE also .
Should we fix them ?
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17450) TablePermission.equals throws NPE after support namespace
[
https://issues.apache.org/jira/browse/HBASE-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17450:
Description:
below unit test will throws NullPointerException:
{code}
p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
assertEquals(p1, p2);
{code}
this bug was introduced after constructor of TablePermission for namespace
provided.
was:
below unit test will throws NullPointerException:
{code}
p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
assertEquals(p1, p2);
{code}
this bug was introduced after construct method for namespace provided.
> TablePermission.equals throws NPE after support namespace
> ---
>
> Key: HBASE-17450
> URL: https://issues.apache.org/jira/browse/HBASE-17450
> Project: HBase
> Issue Type: Bug
> Components: findbugs
>Reporter: huzheng
>Assignee: huzheng
>
> below unit test will throws NullPointerException:
> {code}
> p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
> assertEquals(p1, p2);
> {code}
> this bug was introduced after constructor of TablePermission for namespace
> provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-17450) TablePermission.equals throws NPE after support namespace
huzheng created HBASE-17450:
---
Summary: TablePermission.equals throws NPE after support
namespace
Key: HBASE-17450
URL: https://issues.apache.org/jira/browse/HBASE-17450
Project: HBase
Issue Type: Bug
Components: findbugs
Reporter: huzheng
Assignee: huzheng
below unit test will throws NullPointerException:
{code}
p1 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
p2 = new TablePermission(TEST_NAMESPACE, TablePermission.Action.READ);
assertEquals(p1, p2);
{code}
this bug was introduced after construct method for namespace provided.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17381:
Assignee: huzheng
Status: Patch Available (was: Open)
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Attachments: HBASE-17381.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15801468#comment-15801468
]
huzheng edited comment on HBASE-17381 at 1/5/17 2:22 PM:
-
[~ghelmling] I upload a patch to abort region server if OOME occur. for other
exception cases, I throw them (ReplicationSourceWorkerThread exit and region
server keep running) because it seems hard to make sure whether it's
recoverable case or not .
was (Author: openinx):
[~ghelmling] I upload a patch to abort region server if OOME occur. for other
exception cases, I throw them because it seems hard to make sure whether
it's recoverable case or not (ReplicationSourceWorkerThread exit and region
server keep running).
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
> Attachments: HBASE-17381.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15801468#comment-15801468
]
huzheng commented on HBASE-17381:
-
[~ghelmling] I upload a patch to abort region server if OOME occur. for other
exception cases, I throw them because it seems hard to make sure whether
it's recoverable case or not (ReplicationSourceWorkerThread exit and region
server keep running).
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
> Attachments: HBASE-17381.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17381:
Attachment: HBASE-17381.patch
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
> Attachments: HBASE-17381.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17381:
Status: Open (was: Patch Available)
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-17381:
Status: Patch Available (was: Open)
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15794980#comment-15794980
]
huzheng edited comment on HBASE-17381 at 1/4/17 2:00 AM:
-
Yeah, if OOME occur, we can handle it like region server main thread do :
{code}
try{
// ReplicationSourceWorkerThread logic ...
}catch(Throwable t){
if (checkOOME(t)) {
abort("Unhandled exception: " + t.getMessage(), t);
}
}
{code}
was (Author: openinx):
Yeah, if OOME occur, we can handle it like region server main thread do :
{code}
try{
// ReplicationSourceWorkerThread logic ...
}catch(Throwable t){
if (!checkOOME(t)) {
abort("Unhandled exception: " + t.getMessage(), t);
}
}
{code}
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15795023#comment-15795023
]
huzheng commented on HBASE-17381:
-
The trouble is: we need to list recoverable and un-recoverable cases , and
handle them in correct way.
Can we create a patch handle OOME firstly ?
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15794980#comment-15794980
]
huzheng commented on HBASE-17381:
-
Yeah, if OOME occur, we can handle it like region server main thread do :
{code}
try{
// ReplicationSourceWorkerThread logic ...
}catch(Throwable t){
if (!checkOOME(t)) {
abort("Unhandled exception: " + t.getMessage(), t);
}
}
{code}
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15787248#comment-15787248
]
huzheng commented on HBASE-17381:
-
Hi Gary Helmling, After check code base, Abort regionserver is a solution to
avoid indefinitely replication queue backup if ReplicationSourceWorkerThread
crashed, Another way, I think, maybe we can restart
ReplicationSourceWorkerThread when unexpected exception occur.
I think restart ReplicationSourceWorkerThread for crashed peer seems more
friendly. How do you think ?
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-16990) Shell tool to dump table schemas and table privileges
[
https://issues.apache.org/jira/browse/HBASE-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng reassigned HBASE-16990:
---
Assignee: huzheng
> Shell tool to dump table schemas and table privileges
> -
>
> Key: HBASE-16990
> URL: https://issues.apache.org/jira/browse/HBASE-16990
> Project: HBase
> Issue Type: New Feature
> Components: tooling
>Reporter: huzheng
>Assignee: huzheng
>Priority: Minor
>
> Recently, we are trying to migrate tables from Cluster-A to Cluster-B, I
> found that HBase lack some useful tools :
> 1. dump table schema, like mysqldump in mysql
> 2. dump table privileges, like pt-show-grants in mysql provided by Percona.
> I think we can add a dump sub-command looks like (JUST simple demo) :
> {code}
> $ ./bin/hbase dump -t test_table --with-privileges > ~/test_table.hsh
> $ cat ~/test_table.hsh
> create 'test_table', {NAME=>'f1'}
> grant 'test_user', 'RW', 'test_table'
> {code}
> Maybe I can contribute ... :)
> How do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng reopened HBASE-16886: - > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: 16886.addendum, 16886.v4.branch-1.patch, > HBASE-16886.v0.patch, HBASE-16886.v1.patch, HBASE-16886.v2.patch, > HBASE-16886.v3.patch, HBASE-16886.v4.0.98.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.master.patch, > TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-16886: Resolution: Resolved Status: Resolved (was: Patch Available) > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: 16886.addendum, 16886.v4.branch-1.patch, > HBASE-16886.v0.patch, HBASE-16886.v1.patch, HBASE-16886.v2.patch, > HBASE-16886.v3.patch, HBASE-16886.v4.0.98.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.master.patch, > TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16990) Shell tool to dump table schemas and table privileges
[
https://issues.apache.org/jira/browse/HBASE-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huzheng updated HBASE-16990:
Description:
Recently, we are trying to migrate tables from Cluster-A to Cluster-B, I
found that HBase lack some useful tools :
1. dump table schema, like mysqldump in mysql
2. dump table privileges, like pt-show-grants in mysql provided by Percona.
I think we can add a dump sub-command looks like (JUST simple demo) :
{code}
$ ./bin/hbase dump -t test_table --with-privileges > ~/test_table.hsh
$ cat ~/test_table.hsh
create 'test_table', {NAME=>'f1'}
grant 'test_user', 'RW', 'test_table'
{code}
Maybe I can contribute ... :)
How do you think ?
was:
Recently, we are trying to migrate tables from Cluster-A to Cluster-B, I
found that HBase lack some useful tools :
1. dump table schema, like mysqldump in mysql
2. dump table privileges, like pt-show-grants in mysql which is provide by
Percona.
I think we can add a dump sub-command looks like (JUST simple demo) :
{code}
$ ./bin/hbase dump -t test_table --with-privileges > ~/test_table.hsh
$ cat ~/test_table.hsh
create 'test_table', {NAME=>'f1'}
grant 'test_user', 'RW', 'test_table'
{code}
Maybe I can contribute ... :)
How do you think ?
> Shell tool to dump table schemas and table privileges
> -
>
> Key: HBASE-16990
> URL: https://issues.apache.org/jira/browse/HBASE-16990
> Project: HBase
> Issue Type: New Feature
> Components: tooling
>Reporter: huzheng
>Priority: Minor
>
> Recently, we are trying to migrate tables from Cluster-A to Cluster-B, I
> found that HBase lack some useful tools :
> 1. dump table schema, like mysqldump in mysql
> 2. dump table privileges, like pt-show-grants in mysql provided by Percona.
> I think we can add a dump sub-command looks like (JUST simple demo) :
> {code}
> $ ./bin/hbase dump -t test_table --with-privileges > ~/test_table.hsh
> $ cat ~/test_table.hsh
> create 'test_table', {NAME=>'f1'}
> grant 'test_user', 'RW', 'test_table'
> {code}
> Maybe I can contribute ... :)
> How do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-16990) Shell tool to dump table schemas and table privileges
huzheng created HBASE-16990:
---
Summary: Shell tool to dump table schemas and table privileges
Key: HBASE-16990
URL: https://issues.apache.org/jira/browse/HBASE-16990
Project: HBase
Issue Type: New Feature
Components: tooling
Reporter: huzheng
Priority: Minor
Recently, we are trying to migrate tables from Cluster-A to Cluster-B, I
found that HBase lack some useful tools :
1. dump table schema, like mysqldump in mysql
2. dump table privileges, like pt-show-grants in mysql which is provide by
Percona.
I think we can add a dump sub-command looks like (JUST simple demo) :
{code}
$ ./bin/hbase dump -t test_table --with-privileges > ~/test_table.hsh
$ cat ~/test_table.hsh
create 'test_table', {NAME=>'f1'}
grant 'test_user', 'RW', 'test_table'
{code}
Maybe I can contribute ... :)
How do you think ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15614147#comment-15614147 ] huzheng commented on HBASE-16886: - Fine , thanks. > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: 16886.addendum, 16886.v4.branch-1.patch, > HBASE-16886.v0.patch, HBASE-16886.v1.patch, HBASE-16886.v2.patch, > HBASE-16886.v3.patch, HBASE-16886.v4.0.98.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.master.patch, > TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15614021#comment-15614021 ] huzheng commented on HBASE-16886: - Thanks for reviewing and commiting. Can I update the issue to be Resolved ? > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: 16886.addendum, 16886.v4.branch-1.patch, > HBASE-16886.v0.patch, HBASE-16886.v1.patch, HBASE-16886.v2.patch, > HBASE-16886.v3.patch, HBASE-16886.v4.0.98.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.master.patch, > TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15612028#comment-15612028 ] huzheng commented on HBASE-16886: - Thanks very much. -:) > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: 16886.v4.branch-1.patch, HBASE-16886.v0.patch, > HBASE-16886.v1.patch, HBASE-16886.v2.patch, HBASE-16886.v3.patch, > HBASE-16886.v4.0.98.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.master.patch, TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[
https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15611021#comment-15611021
]
huzheng commented on HBASE-16886:
-
Hi, [~tedyu] all unit test seems passed.
TestMultiTableSnapshotInputFormat test is OK in my desktop, and the failed
cause of Hadoop QA is ：
{code}
java.io.IOException: Unable to create region directory:
/tmp/scantest2_snapshot__043a17e4-3572-4aea-9bcb-330edecd5a39/data/default/scantest2/1bbfd104c261fc1d4677d66728299f51
{code}
after checked the code files, it seems nothing to do with this patch. but
this ut case is unstable . Any advise ?
Thanks.
> hbase-client: scanner with reversed=true and small=true gets no result
> --
>
> Key: HBASE-16886
> URL: https://issues.apache.org/jira/browse/HBASE-16886
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23
>Reporter: huzheng
> Labels: patch
> Attachments: 16886.v4.branch-1.patch, HBASE-16886.v0.patch,
> HBASE-16886.v1.patch, HBASE-16886.v2.patch, HBASE-16886.v3.patch,
> HBASE-16886.v4.0.98.patch, HBASE-16886.v4.branch-1.patch,
> HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch,
> HBASE-16886.v4.master.patch, TestReversedSmallScan.java
>
>
> Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all
> rowKeys are located in region [d, +oo). using a Reversed Small Scanner will
> get no result.
> Attached file show this failed test case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16886) hbase-client: scanner with reversed=true and small=true gets no result
[ https://issues.apache.org/jira/browse/HBASE-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huzheng updated HBASE-16886: Attachment: HBASE-16886.v4.branch-1.patch > hbase-client: scanner with reversed=true and small=true gets no result > -- > > Key: HBASE-16886 > URL: https://issues.apache.org/jira/browse/HBASE-16886 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.3, 1.1.7, 0.98.23 >Reporter: huzheng > Labels: patch > Attachments: 16886.v4.branch-1.patch, HBASE-16886.v0.patch, > HBASE-16886.v1.patch, HBASE-16886.v2.patch, HBASE-16886.v3.patch, > HBASE-16886.v4.0.98.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.branch-1.patch, HBASE-16886.v4.branch-1.patch, > HBASE-16886.v4.master.patch, TestReversedSmallScan.java > > > Assume HBase have four regions (-oo, b), [b, c), [c, d), [d,+oo) , and all > rowKeys are located in region [d, +oo). using a Reversed Small Scanner will > get no result. > Attached file show this failed test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
