[jira] [Commented] (HBASE-18893) Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using ModifyTableProcedure
[ https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216360#comment-16216360 ] stack commented on HBASE-18893: --- Not for alpha-4 [~mdrob]? Or you want a test run first before committing? > Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using > ModifyTableProcedure > > > Key: HBASE-18893 > URL: https://issues.apache.org/jira/browse/HBASE-18893 > Project: HBase > Issue Type: Bug > Components: Coprocessors, master >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: HBASE-18893.patch, HBASE-18893.v2.patch, > HBASE-18893.v3.patch, HBASE-18893.v4.patch > > > The shell changed from using separate add/modify/delete column calls to > funneling everything through modify table for performance reasons. We know > that using modify table works for everything. Let's drop the old code for > Add/Modify/Delete Column so that we have a lower maintenance burden and fewer > code paths to reason about. > Was: shell 'alter' command no longer distinguishes column > add/modify/delete > After HBASE-15641 all 'alter' commands go through a single modifyTable call > at the end, so we no longer can easily distinguish add, modify, and delete > column events. This potentially affects coprocessors that needed the update > notifications for new or removed columns. > Let's let the shell still make separate behaviour calls like it did before > without undoing the batching that seems pretty useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216359#comment-16216359 ] stack commented on HBASE-18946: --- bq. But still in these cases the bulking mechanism is not a logical bulking instead it depends on the timed wait and the size of the queue. See in RPC where it is batching requests. But if you want discernment regards where Regions go on a cluster, thats the Balancer's job. It has all the sources to pull on. Can't it tell members of a ReadReplica set? Can't it do lookup to see where the other replicas are out on the cluster before it makes a plan for current replia? The AssignProcedure is about assigning a single Procedure, nothing else. If we start bulking it up with other concerns, we'll be back to the fuzzy AMv1 story. When the Balancer is passed a List, could it look at the list first to find replicas and group? > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18946.patch, HBASE-18946.patch, > TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18905) Allow CPs to request flush on Region and know the completion of the requested flush
[ https://issues.apache.org/jira/browse/HBASE-18905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216353#comment-16216353 ] Anoop Sam John commented on HBASE-18905: Yes. Internally when we do flush/compaction, the Dummy tracker is been used. When requesting flush/compaction from the CP, they can create a Tracker instance and pass to core. This is like a Listener . > Allow CPs to request flush on Region and know the completion of the requested > flush > --- > > Key: HBASE-18905 > URL: https://issues.apache.org/jira/browse/HBASE-18905 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Duo Zhang > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18905.patch > > > Follow up for HBASE-18183 > As per that Jira, we keep only requestCompaction API in Region. We did not > have any such for flush in Region. Only API which was there is a flush which > will block the callee unless flush is done. This issue has to tacke > 1. Decide whether we need a requestFlush in Region and if so add > 2. Whether the requestCompaction (And requestFlush too) should return a > Future? Right now the former do not return any but allow to pass a > CompactionLifeCycleTracker which will get notified on start and end of > compaction. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216350#comment-16216350 ] Hudson commented on HBASE-16338: FAILURE: Integrated in Jenkins build HBase-2.0 #739 (See [https://builds.apache.org/job/HBase-2.0/739/]) HBASE-16338 Remove Jackson1 deps (mdrob: rev 34df2e665e3c9e11ed590a32bc55cf2de1e25818) * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestMultiRowResource.java * (edit) hbase-server/src/main/resources/hbase-webapps/master/processMaster.jsp * (edit) hbase-shell/src/main/ruby/hbase/taskmonitor.rb * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestDeleteRow.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketAllocator.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/util/JSONMetricUtil.java * (edit) hbase-mapreduce/pom.xml * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/RowModel.java * (edit) hbase-shaded/hbase-shaded-mapreduce/pom.xml * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestOperation.java * (edit) hbase-server/src/main/resources/hbase-webapps/regionserver/processRS.jsp * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/util/JsonMapper.java * (edit) hbase-server/src/main/resources/hbase-webapps/master/processRS.jsp * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/RESTApiClusterManager.java * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestBlockCacheReporting.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/StorageClusterVersionModel.java * (edit) hbase-server/pom.xml * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/TableSchemaModel.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALPrettyPrinter.java * (add) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/ProtobufStreamingOutput.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/NamespacesModel.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/HBaseRESTTestingUtility.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestVersionResource.java * (edit) hbase-spark/pom.xml * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockCacheUtil.java * (edit) hbase-shaded/pom.xml * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/CellModel.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestJSONMetricUtil.java * (edit) dev-support/hbase-personality.sh * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestTableScan.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/AgeSnapshot.java * (edit) pom.xml * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestSchemaResource.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/ColumnSchemaModel.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/TableScanResource.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/StorageClusterStatusModel.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/monitoring/MonitoredTaskImpl.java * (edit) hbase-rest/pom.xml * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestColumnSchemaModel.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestNamespacesInstanceResource.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * (delete) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/ProtobufStreamingUtil.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java * (edit) hbase-client/pom.xml * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/TestPerformanceEvaluation.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestModelBase.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/util/JSONBean.java * (edit) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RESTServer.java * (edit) hbase-it/pom.xml * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestTableSchemaModel.java > update jackson to 2.y > - > > Key: HBASE-16338 > URL: https://issues.apache.org/jira/browse/HBASE-16338 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Sean Busbey >Assignee: Mike Drob > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: 16338.txt, HBASE-16338.branch-2.patch, > HBASE-16338.v10.patch,
[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216348#comment-16216348 ] ramkrishna.s.vasudevan commented on HBASE-18994: bq.hbase.systemtable.memstore.compacting.type Ya makes sense. This is better. > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18994.patch > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216347#comment-16216347 ] ramkrishna.s.vasudevan commented on HBASE-18946: [~saint@gmail.com] Thanks for the comment. Yes in a way I agree that fixing it in Balancer is best. But still in these cases the bulking mechanism is not a logical bulking instead it depends on the timed wait and the size of the queue. So the balancer may not really know what has been balanced by the time the next bulked set of region comes in. Any suggestions? I can still check if it is possible to make balancer aware of this. But this mechanism solves some more issues in other related areas since we know the set of regions to be balanced at one shot. > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18946.patch, HBASE-18946.patch, > TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params
[
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19048:
--
Attachment: HBASE-19048.master.002.patch
> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch,
> HBASE-19048.master.002.patch
>
>
> These are the ones in MasterObserver
> {code}
> preAbortProcedure- ProcedureExecutor
> postGetProcedures- Procedure
> postGetLocks - LockedResource
> preRequestLock - LockType
> postRequestLock - LockType
> preLockHeartbeat - LockProcedure
> postLockHeartbeat- LockProcedure
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params
[
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216346#comment-16216346
]
stack commented on HBASE-19048:
---
.002 Rebase.
> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch,
> HBASE-19048.master.002.patch
>
>
> These are the ones in MasterObserver
> {code}
> preAbortProcedure- ProcedureExecutor
> postGetProcedures- Procedure
> postGetLocks - LockedResource
> preRequestLock - LockType
> postRequestLock - LockType
> preLockHeartbeat - LockProcedure
> postLockHeartbeat- LockProcedure
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216345#comment-16216345 ] stack commented on HBASE-18994: --- I don't get that from the patch. Makes sense when you spell it out. Suggestion: hbase.systemtable.memstore.compacting.type If not set, just use default memstore type? > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18994.patch > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params
[
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216343#comment-16216343
]
Hadoop QA commented on HBASE-19048:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-19048 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19048 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893617/HBASE-19048.master.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9367/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch
>
>
> These are the ones in MasterObserver
> {code}
> preAbortProcedure- ProcedureExecutor
> postGetProcedures- Procedure
> postGetLocks - LockedResource
> preRequestLock - LockType
> postRequestLock - LockType
> preLockHeartbeat - LockProcedure
> postLockHeartbeat- LockProcedure
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19073) Cleanup CoordinatedStateManager
[
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216342#comment-16216342
]
Hadoop QA commented on HBASE-19073:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-19073 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19073 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893623/HBASE-19073.master.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9366/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Cleanup CoordinatedStateManager
> ---
>
> Key: HBASE-19073
> URL: https://issues.apache.org/jira/browse/HBASE-19073
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19073.master.001.patch
>
>
> - Remove the configuration hbase.coordinated.state.manager.class
> - Keep following interface since they nicely separate ZK based
> implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination,
> ProcedureCoordinatorRpcs, ProcedureMemberRpcs
> - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single
> CSM interface.
> - Don't pass whole CSM object around (with server in it which gives acess to
> pretty much everything), only pass the relevant dependencies.
> Discussion thread on dev@ mailing list.
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19076) Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
[
https://issues.apache.org/jira/browse/HBASE-19076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Qilin Cao updated HBASE-19076:
--
Description:
After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
with the hbase-error-prone module.
{code}
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
(min-maven-min-java-banned-xerces) @ hbase-error-prone ---
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
hbase-error-prone ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
with message:
We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{code}
was:
After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
with the hbase-error-prone module.
{code}
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone ---
[INFO] Deleting
/home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
(min-maven-min-java-banned-xerces) @ hbase-error-prone ---
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
hbase-error-prone ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
with message:
We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{code}
> Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
>
>
> Key: HBASE-19076
> URL: https://issues.apache.org/jira/browse/HBASE-19076
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
>Reporter: Qilin Cao
>Assignee: Qilin Cao
>Priority: Blocker
> Attachments: HBASE-19076.patch
>
>
> After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
> with the hbase-error-prone module.
> {code}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
> (min-maven-min-java-banned-xerces) @ hbase-error-prone ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
> hbase-error-prone ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216340#comment-16216340 ] stack commented on HBASE-18946: --- We already have a bulking mechanism below AssignProcedure in the RPC. Why ain't we making this change in the balancer. It knows all. Doing it in the AssignProcedure makes it carry state when we've been doing our best to make it a simple machine. > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18946.patch, HBASE-18946.patch, > TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216337#comment-16216337 ] ramkrishna.s.vasudevan commented on HBASE-18994: If it is NONE - the default memstore is instantiated. If the config says do not use the default memstore type then we make the inMemoryCompaction type as BASIC which will instantiate the Compacting memstore and in Compacting Memstore BASIC is the default (since we also have EAGER). > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18994.patch > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[
https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216334#comment-16216334
]
stack commented on HBASE-18994:
---
If default is set, we make compaction NONE, else we make it the 'default'?
272 if (defaultMemstoreForSystemTables) {
273 inMemoryCompaction = MemoryCompactionPolicy.NONE;
274 } else {
275 // basic is the default type for compacting memstore
276 inMemoryCompaction = MemoryCompactionPolicy.BASIC;
277 }
> Decide if META/System tables should use Compacting Memstore or Default
> Memstore
> ---
>
> Key: HBASE-18994
> URL: https://issues.apache.org/jira/browse/HBASE-18994
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18994.patch
>
>
> HBASE-18992 brought this topic. Currently META is also using Compacting
> Memstore. We should decide if system tables can go with Default memstore only.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
[ https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216330#comment-16216330 ] stack commented on HBASE-18233: --- [~allan163] We don't need this restoration of old behavior around locking in branch-2? I thought we had to forward-port this one once it made it into 1.2? (My fault for not writing this down). > We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock > - > > Key: HBASE-18233 > URL: https://issues.apache.org/jira/browse/HBASE-18233 > Project: HBase > Issue Type: Bug >Affects Versions: 1.2.7 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7 > > Attachments: HBASE-18233-branch-1.2.patch, > HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch, > HBASE-18233-branch-1.2.v4 (1).patch, HBASE-18233-branch-1.2.v4 (1).patch, > HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch, > HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch, > HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch > > > Please refer to the discuss in HBASE-18144 > https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216329#comment-16216329
]
Hudson commented on HBASE-19072:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #253 (See
[https://builds.apache.org/job/HBase-1.3-IT/253/])
HBASE-19072 Missing beak in catch block of InterruptedException in (tedyu: rev
447154dc079fdf77636a341a13b7c5a9e647df01)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18994: --- Status: Patch Available (was: Open) > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18994.patch > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18994: --- Attachment: HBASE-18994.patch Simple patch. Any better name for the config? > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18994.patch > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216323#comment-16216323
]
Hudson commented on HBASE-19072:
SUCCESS: Integrated in Jenkins build HBase-1.2-IT #987 (See
[https://builds.apache.org/job/HBase-1.2-IT/987/])
HBASE-19072 Missing beak in catch block of InterruptedException in (tedyu: rev
b4e6eae5ba1bf00e7b413df618b5c44b088ed6fb)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement
[
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216322#comment-16216322
]
Hadoop QA commented on HBASE-19057:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-19057 does not apply to HBASE-18410. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19057 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893635/HBASE-19057-HBASE-18410.v4.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9363/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch,
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch,
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch,
> HBASE-19057-HBASE-18410.v4.patch
>
>
> Open this issue to fix conflict , run HadoopQA and gather other feedback.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19047) CP exposed Scanner types should not extend Shipper
[ https://issues.apache.org/jira/browse/HBASE-19047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216310#comment-16216310 ] stack commented on HBASE-19047: --- #2 ? > CP exposed Scanner types should not extend Shipper > -- > > Key: HBASE-19047 > URL: https://issues.apache.org/jira/browse/HBASE-19047 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-alpha-4 > > > Shipper is a IA.Private interface and very much internal.. > Right now CP exposed RegionScanner is extending this and so exposing the > shipped() method. This by mistake is called, can harm the correctness of the > cells in the Results. > preScannerOpen() allowing to return a new Scanner is also problematic now. > This can allow users to create a Region scanner from Region and then wrap it > and return back (Well same can be done by postScannerOpen also), it can so > happen that the wrapper is not implementing the shipped() properly. In any > way exposing the shipped () is problematic. > Solution > 1. Remove preScannerOpen() , the use case I can think of is wrapping the > original scanner. The original scanner can be created by Region.getScanner > way only.. May be no need to remove this hook. Just remove the ability for > it to return a RegionScanner instance. Call this with the Scan object and > the CP can change the Scan object if they want. > 2. Let RegionScanner not extending Shipper but only RegionScannerImpl > implements this > 3. We have ref to the RegionScanner created by core and let that be used by > RegionScannerShippedCallBack when the post hook doing a wrap. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18994: -- Fix Version/s: (was: 2.0.0-alpha-4) 2.0.0-beta-1 > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore
[ https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216309#comment-16216309 ] stack commented on HBASE-18994: --- Pushing out. Pull in if gets patch. > Decide if META/System tables should use Compacting Memstore or Default > Memstore > --- > > Key: HBASE-18994 > URL: https://issues.apache.org/jira/browse/HBASE-18994 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > > HBASE-18992 brought this topic. Currently META is also using Compacting > Memstore. We should decide if system tables can go with Default memstore only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[ https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216305#comment-16216305 ] stack commented on HBASE-19074: --- .002 Includes deprecations of WALObserver and RegionObserver methods that expose IA.Private. Done w/ my survey of *Observer classes. > Miscellaneous Observer cleanups > --- > > Key: HBASE-19074 > URL: https://issues.apache.org/jira/browse/HBASE-19074 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19074.master.001.patch, > HBASE-19074.master.002.patch > > > Going through Observers after fixing up MasterObserver, i see a few > violations such as Store returning a MemStoreSize instance (which would let > coprocessors inc/dec MemStore size which would mess us up). This issue is > about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19074) Miscellaneous Observer cleanups
[ https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19074: -- Attachment: HBASE-19074.master.002.patch > Miscellaneous Observer cleanups > --- > > Key: HBASE-19074 > URL: https://issues.apache.org/jira/browse/HBASE-19074 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19074.master.001.patch, > HBASE-19074.master.002.patch > > > Going through Observers after fixing up MasterObserver, i see a few > violations such as Store returning a MemStoreSize instance (which would let > coprocessors inc/dec MemStore size which would mess us up). This issue is > about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216304#comment-16216304
]
stack commented on HBASE-19074:
---
Ditto in WALObserver, I made the Deprecated for now.
{code}
/**
* Called before a {@link WALEdit}
* is writen to WAL.
*
* @return true if default behavior should be bypassed, false otherwise
* @deprecated Since hbase-2.0.0. To be replaced with an alternative that
does not expose
* InterfaceAudience classes such as WALKey and WALEdit. Will be removed in
hbase-3.0.0.
*/
// TODO: return value is not used
@Deprecated
default boolean preWALWrite(ObserverContext ctx,
RegionInfo info, WALKey logKey, WALEdit logEdit) throws IOException {
return false;
}
/**
* Called after a {@link WALEdit}
* is writen to WAL.
* @deprecated Since hbase-2.0.0. To be replaced with an alternative that
does not expose
* InterfaceAudience classes such as WALKey and WALEdit. Will be removed in
hbase-3.0.0.
*/
@Deprecated
default void postWALWrite(ObserverContext ctx,
RegionInfo info, WALKey logKey, WALEdit logEdit) throws IOException {}
{code}
> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch,
> HBASE-19074.master.002.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few
> violations such as Store returning a MemStoreSize instance (which would let
> coprocessors inc/dec MemStore size which would mess us up). This issue is
> about cleaning these remainders up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216303#comment-16216303
]
stack commented on HBASE-19074:
---
Ditto in WALObserver, I made the Deprecated for now.
{code}
/**
* Called before a {@link WALEdit}
* is writen to WAL.
*
* @return true if default behavior should be bypassed, false otherwise
* @deprecated Since hbase-2.0.0. To be replaced with an alternative that
does not expose
* InterfaceAudience classes such as WALKey and WALEdit. Will be removed in
hbase-3.0.0.
*/
// TODO: return value is not used
@Deprecated
default boolean preWALWrite(ObserverContext ctx,
RegionInfo info, WALKey logKey, WALEdit logEdit) throws IOException {
return false;
}
/**
* Called after a {@link WALEdit}
* is writen to WAL.
* @deprecated Since hbase-2.0.0. To be replaced with an alternative that
does not expose
* InterfaceAudience classes such as WALKey and WALEdit. Will be removed in
hbase-3.0.0.
*/
@Deprecated
default void postWALWrite(ObserverContext ctx,
RegionInfo info, WALKey logKey, WALEdit logEdit) throws IOException {}
{code}
> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch,
> HBASE-19074.master.002.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few
> violations such as Store returning a MemStoreSize instance (which would let
> coprocessors inc/dec MemStore size which would mess us up). This issue is
> about cleaning these remainders up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18352) Enable Replica tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216297#comment-16216297 ] ramkrishna.s.vasudevan edited comment on HBASE-18352 at 10/24/17 4:46 AM: -- [~huaxiang] The only difference between the patch in HBASE-18946 and the one here is that now I do bulk assign in ServerCrashProcedure once we know all the regions that were hosted in the crashed server. So the balancer is able to make a plan out of it for the whole lot. That patch attached here needs some refinement to see if we should do that only if there are replica regions. was (Author: ram_krish): [~huaxiang] The only difference is that now I do bulk assign in ServerCrashProcedure once we know all the regions that were hosted in the crashed server. So the balancer is able to make a plan out of it for the whole lot. That patch attached here needs some refinement to see if we should do that only if there are replica regions. > Enable Replica tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18352 > URL: https://issues.apache.org/jira/browse/HBASE-18352 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Attachments: HBASE-18946_1.patch > > > The following replica tests were disabled by Core Proc-V2 AM in HBASE-14614: > - Disabled parts of...testCreateTableWithMultipleReplicas in > TestMasterOperationsForRegionReplicas There is an issue w/ assigning more > replicas if number of replicas is changed on us. See '/* DISABLED! FOR > NOW'. > - Disabled testRegionReplicasOnMidClusterHighReplication in > TestStochasticLoadBalancer2 > - Disabled testFlushAndCompactionsInPrimary in TestRegionReplicas > This JIRA tracks the work to enable them (or modify/remove if not applicable). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216298#comment-16216298
]
Hudson commented on HBASE-19072:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #337 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/337/])
HBASE-19072 Missing beak in catch block of InterruptedException in (tedyu: rev
447154dc079fdf77636a341a13b7c5a9e647df01)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216299#comment-16216299
]
Hudson commented on HBASE-19072:
FAILURE: Integrated in Jenkins build HBase-1.2-JDK7 #251 (See
[https://builds.apache.org/job/HBase-1.2-JDK7/251/])
HBASE-19072 Missing beak in catch block of InterruptedException in (tedyu: rev
b4e6eae5ba1bf00e7b413df618b5c44b088ed6fb)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216296#comment-16216296
]
Hudson commented on HBASE-19072:
FAILURE: Integrated in Jenkins build HBase-1.2-JDK8 #248 (See
[https://builds.apache.org/job/HBase-1.2-JDK8/248/])
HBASE-19072 Missing beak in catch block of InterruptedException in (tedyu: rev
b4e6eae5ba1bf00e7b413df618b5c44b088ed6fb)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18352) Enable Replica tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216297#comment-16216297 ] ramkrishna.s.vasudevan commented on HBASE-18352: [~huaxiang] The only difference is that now I do bulk assign in ServerCrashProcedure once we know all the regions that were hosted in the crashed server. So the balancer is able to make a plan out of it for the whole lot. That patch attached here needs some refinement to see if we should do that only if there are replica regions. > Enable Replica tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18352 > URL: https://issues.apache.org/jira/browse/HBASE-18352 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Attachments: HBASE-18946_1.patch > > > The following replica tests were disabled by Core Proc-V2 AM in HBASE-14614: > - Disabled parts of...testCreateTableWithMultipleReplicas in > TestMasterOperationsForRegionReplicas There is an issue w/ assigning more > replicas if number of replicas is changed on us. See '/* DISABLED! FOR > NOW'. > - Disabled testRegionReplicasOnMidClusterHighReplication in > TestStochasticLoadBalancer2 > - Disabled testFlushAndCompactionsInPrimary in TestRegionReplicas > This JIRA tracks the work to enable them (or modify/remove if not applicable). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216292#comment-16216292
]
Hudson commented on HBASE-19072:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #321 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/321/])
HBASE-19072 Missing beak in catch block of InterruptedException in (tedyu: rev
447154dc079fdf77636a341a13b7c5a9e647df01)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216293#comment-16216293
]
stack commented on HBASE-19074:
---
Looking at other *Observers...
In RegionObserver, I see this:
{code}
/**
* Called before a {@link WALEdit}
* replayed for this region.
* @param ctx the environment provided by the region server
*/
default void preWALRestore(ObserverContext ctx,
RegionInfo info, WALKey logKey, WALEdit logEdit) throws IOException {}
/**
* Called after a {@link WALEdit}
* replayed for this region.
* @param ctx the environment provided by the region server
*/
default void postWALRestore(ObserverContext ctx,
RegionInfo info, WALKey logKey, WALEdit logEdit) throws IOException {}
{code}
WALKey and WALEdit are Private. I don't think I can remove these. Will
deprecate with no replacement. In hbase 3, hopefully this
WALEdit/WALKey/WALEdit/WALEntry gets cleaned up.
> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few
> violations such as Store returning a MemStoreSize instance (which would let
> coprocessors inc/dec MemStore size which would mess us up). This issue is
> about cleaning these remainders up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216288#comment-16216288 ] Hudson commented on HBASE-15631: FAILURE: Integrated in Jenkins build HBase-1.5 #110 (See [https://builds.apache.org/job/HBase-1.5/110/]) HBASE-15631 Backport Regionserver Groups (HBASE-6721) to branch-1 (apurtell: rev 64328caef0bb712bb69d0241b4b8b3474a82702c) * (add) hbase-shell/src/main/ruby/shell/commands/get_table_rsgroup.rb * (add) hbase-it/src/test/rsgroup/org/apache/hadoop/hbase/rsgroup/IntegrationTestRSGroup.java * (add) hbase-rsgroup/pom.xml * (edit) hbase-shell/src/main/ruby/hbase.rb * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/normalizer/TestSimpleRegionNormalizer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseMasterObserver.java * (add) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RSGroupAdminProtos.java * (edit) hbase-shell/src/main/ruby/hbase/hbase.rb * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroups.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/MasterObserver.java * (edit) hbase-shell/src/test/ruby/test_helper.rb * (add) hbase-shell/src/test/ruby/shell/rsgroup_shell_test.rb * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsOfflineMode.java * (add) hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/master/balancer/TestRSGroupBasedLoadBalancer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * (edit) hbase-protocol/pom.xml * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupProtobufUtil.java * (add) hbase-shell/src/main/ruby/shell/commands/add_rsgroup.rb * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * (edit) hbase-shell/src/test/java/org/apache/hadoop/hbase/client/TestShell.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java * (add) hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java * (add) hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java * (add) hbase-shell/src/main/ruby/hbase/rsgroup_admin.rb * (edit) hbase-it/pom.xml * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminClient.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterCoprocessorHost.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestMasterStatusServlet.java * (add) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RSGroupProtos.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManager.java * (edit) hbase-shell/src/main/ruby/shell.rb * (add) hbase-shell/src/main/ruby/shell/commands/remove_rsgroup.rb * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsBase.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/LoadBalancer.java * (add) hbase-protocol/src/main/protobuf/RSGroupAdmin.proto * (add) hbase-shell/src/test/rsgroup/org/apache/hadoop/hbase/client/rsgroup/TestShellRSGroups.java * (edit) pom.xml * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseMasterAndRegionObserver.java * (edit) hbase-shell/pom.xml * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/VerifyingRSGroupAdminClient.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java * (add) hbase-shell/src/main/ruby/shell/commands/move_tables_rsgroup.rb * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManagerImpl.java * (edit) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClientProtos.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * (add) hbase-shell/src/main/ruby/shell/commands/balance_rsgroup.rb * (add) hbase-shell/src/main/ruby/shell/commands/move_servers_tables_rsgroup.rb * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ServerName.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminServer.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupableBalancer.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdmin.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (edit)
[jira] [Commented] (HBASE-6721) RegionServer Group based Assignment
[ https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216289#comment-16216289 ] Hudson commented on HBASE-6721: --- FAILURE: Integrated in Jenkins build HBase-1.5 #110 (See [https://builds.apache.org/job/HBase-1.5/110/]) HBASE-15631 Backport Regionserver Groups (HBASE-6721) to branch-1 (apurtell: rev 64328caef0bb712bb69d0241b4b8b3474a82702c) * (edit) pom.xml * (edit) hbase-protocol/pom.xml * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupProtobufUtil.java * (add) hbase-it/src/test/rsgroup/org/apache/hadoop/hbase/rsgroup/IntegrationTestRSGroup.java * (add) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RSGroupProtos.java * (edit) hbase-shell/src/main/ruby/shell/commands.rb * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/master/balancer/TestRSGroupBasedLoadBalancer.java * (edit) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ClientProtos.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (add) hbase-shell/src/main/ruby/shell/commands/balance_rsgroup.rb * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupSerDe.java * (add) hbase-shell/src/main/ruby/shell/commands/move_tables_rsgroup.rb * (edit) hbase-shell/src/test/java/org/apache/hadoop/hbase/client/TestShell.java * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsOfflineMode.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManagerImpl.java * (edit) hbase-shell/src/main/ruby/hbase.rb * (edit) hbase-shell/src/main/ruby/hbase/hbase.rb * (add) hbase-protocol/src/main/protobuf/RSGroup.proto * (add) hbase-shell/src/test/ruby/shell/rsgroup_shell_test.rb * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupableBalancer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterCoprocessorHost.java * (add) hbase-shell/src/main/ruby/shell/commands/get_server_rsgroup.rb * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/LoadBalancer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/normalizer/TestSimpleRegionNormalizer.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdmin.java * (add) hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb * (add) hbase-shell/src/main/ruby/shell/commands/move_servers_tables_rsgroup.rb * (edit) hbase-shell/pom.xml * (add) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RSGroupAdminProtos.java * (add) hbase-shell/src/main/ruby/shell/commands/get_table_rsgroup.rb * (add) hbase-shell/src/main/ruby/hbase/rsgroup_admin.rb * (add) hbase-shell/src/test/rsgroup/org/apache/hadoop/hbase/client/rsgroup/TestShellRSGroups.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java * (edit) hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon * (edit) hbase-it/pom.xml * (add) hbase-common/src/main/java/org/apache/hadoop/hbase/net/Address.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseMasterObserver.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * (add) hbase-shell/src/main/ruby/shell/commands/remove_rsgroup.rb * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockNoopMasterServices.java * (edit) hbase-shell/src/main/ruby/shell.rb * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/MasterObserver.java * (add) hbase-shell/src/main/ruby/shell/commands/move_servers_rsgroup.rb * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/VerifyingRSGroupAdminClient.java * (add) hbase-protocol/src/main/protobuf/RSGroupAdmin.proto * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ServerName.java * (add) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminEndpoint.java * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroups.java * (add) hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsBase.java * (edit)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[ https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216284#comment-16216284 ] stack commented on HBASE-19074: --- [~elserj] They are used by the subclass. Thanks for the review J. > Miscellaneous Observer cleanups > --- > > Key: HBASE-19074 > URL: https://issues.apache.org/jira/browse/HBASE-19074 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19074.master.001.patch > > > Going through Observers after fixing up MasterObserver, i see a few > violations such as Store returning a MemStoreSize instance (which would let > coprocessors inc/dec MemStore size which would mess us up). This issue is > about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19076) Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
[
https://issues.apache.org/jira/browse/HBASE-19076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Qilin Cao updated HBASE-19076:
--
Status: Patch Available (was: Open)
> Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
>
>
> Key: HBASE-19076
> URL: https://issues.apache.org/jira/browse/HBASE-19076
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
>Reporter: Qilin Cao
>Assignee: Qilin Cao
>Priority: Blocker
> Attachments: HBASE-19076.patch
>
>
> After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
> with the hbase-error-prone module.
> {code}
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone
> ---
> [INFO] Deleting
> /home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
> (min-maven-min-java-banned-xerces) @ hbase-error-prone ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
> hbase-error-prone ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19076) Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
[
https://issues.apache.org/jira/browse/HBASE-19076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Qilin Cao updated HBASE-19076:
--
Attachment: HBASE-19076.patch
submit a patch!
> Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
>
>
> Key: HBASE-19076
> URL: https://issues.apache.org/jira/browse/HBASE-19076
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
>Reporter: Qilin Cao
>Assignee: Qilin Cao
>Priority: Blocker
> Attachments: HBASE-19076.patch
>
>
> After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
> with the hbase-error-prone module.
> {code}
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone
> ---
> [INFO] Deleting
> /home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
> (min-maven-min-java-banned-xerces) @ hbase-error-prone ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
> hbase-error-prone ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18905) Allow CPs to request flush on Region and know the completion of the requested flush
[ https://issues.apache.org/jira/browse/HBASE-18905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216281#comment-16216281 ] stack commented on HBASE-18905: --- A tracker is created only when a CP asks to track a flush or compaction? Internally we do not track compaction or flush? > Allow CPs to request flush on Region and know the completion of the requested > flush > --- > > Key: HBASE-18905 > URL: https://issues.apache.org/jira/browse/HBASE-18905 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Duo Zhang > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18905.patch > > > Follow up for HBASE-18183 > As per that Jira, we keep only requestCompaction API in Region. We did not > have any such for flush in Region. Only API which was there is a flush which > will block the callee unless flush is done. This issue has to tacke > 1. Decide whether we need a requestFlush in Region and if so add > 2. Whether the requestCompaction (And requestFlush too) should return a > Future? Right now the former do not return any but allow to pass a > CompactionLifeCycleTracker which will get notified on start and end of > compaction. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216280#comment-16216280
]
Josh Elser commented on HBASE-19074:
{noformat}
+ /**
+ *'dataSize' tracks the Cell's data bytes size alone (Key bytes, value
bytes). A cell's data can
+ * be in on heap or off heap area depending on the MSLAB and its
configuration to be using on heap
+ * or off heap LABs
+ */
+ protected long dataSize;
+
+ /** 'heapSize' tracks all Cell's heap size occupancy. This will include Cell
POJO heap overhead.
+ * When Cells in on heap area, this will include the cells data size as well.
+ */
+ protected long heapSize;
{noformat}
Any reason for the change from {{private}} to {{protected}}? Not a big deal,
just a little curious if there was specific intent (were it me, I'd have left
them private).
Otherwise, your v1 patch looks fine to me pending qa.
> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few
> violations such as Store returning a MemStoreSize instance (which would let
> coprocessors inc/dec MemStore size which would mess us up). This issue is
> about cleaning these remainders up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
[
https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216279#comment-16216279
]
Allan Yang commented on HBASE-18233:
{quote}
I'd like to move on closing this out. Since branch-1* precommit is reliably
timing out, please make a version for master.
{quote}
[~busbey], since HBASE-17924 is already committed to master branch and branch
2.0(HBASE-17924 solved the issue in another way). This issue should not become
a blocker for master branch. we can remove 2.0.0, 1.4.0 from fixed version.
> We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
> -
>
> Key: HBASE-18233
> URL: https://issues.apache.org/jira/browse/HBASE-18233
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.7
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-18233-branch-1.2.patch,
> HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch,
> HBASE-18233-branch-1.2.v4 (1).patch, HBASE-18233-branch-1.2.v4 (1).patch,
> HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch,
> HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch,
> HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch
>
>
> Please refer to the discuss in HBASE-18144
> https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-18846:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to branch-2 and master. Thanks for the review [~mdrob]
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> HBASE-18846.master.006.patch, HBASE-18846.master.007.patch,
> HBASE-18846.master.007.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216270#comment-16216270
]
stack commented on HBASE-18846:
---
Was going to wait for next qa run but looks like none are being scheduled. Will
commit and keep an eye on it When build comes back.
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> HBASE-18846.master.006.patch, HBASE-18846.master.007.patch,
> HBASE-18846.master.007.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase
[
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-19029:
--
Comment: was deleted
(was: [~Apache9], I fixed your comments. Could you check it?)
> Align RPC timout methods in Table and AsyncTableBase
>
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch,
> HBASE-19029.master.002.patch, HBASE-19029.master.002.patch,
> HBASE-19029.master.003.patch, HBASE-19029.master.003.patch,
> HBASE-19029.master.003.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled
> differently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase
[
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216269#comment-16216269
]
Peter Somogyi commented on HBASE-19029:
---
[~Apache9], I fixed your comments. Could you check it?
> Align RPC timout methods in Table and AsyncTableBase
>
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch,
> HBASE-19029.master.002.patch, HBASE-19029.master.002.patch,
> HBASE-19029.master.003.patch, HBASE-19029.master.003.patch,
> HBASE-19029.master.003.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled
> differently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase
[
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216268#comment-16216268
]
Peter Somogyi commented on HBASE-19029:
---
[~Apache9], I fixed your comments. Could you check it?
> Align RPC timout methods in Table and AsyncTableBase
>
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch,
> HBASE-19029.master.002.patch, HBASE-19029.master.002.patch,
> HBASE-19029.master.003.patch, HBASE-19029.master.003.patch,
> HBASE-19029.master.003.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled
> differently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216263#comment-16216263 ] Josh Elser commented on HBASE-17852: Sure thing, boss. Not a problem. Thanks for the book-keeping > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups
[ https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216261#comment-16216261 ] stack commented on HBASE-19074: --- .001 First cut. Breaks MemStoreSize into MemStoreSize (read-only) and MemStoreSizing (read/write). MemStoreSize we allow to Coprocesors. MemStoreSizing we use internally doing MemStore accounting. While this is testing, let me see if other violations in Observers. > Miscellaneous Observer cleanups > --- > > Key: HBASE-19074 > URL: https://issues.apache.org/jira/browse/HBASE-19074 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19074.master.001.patch > > > Going through Observers after fixing up MasterObserver, i see a few > violations such as Store returning a MemStoreSize instance (which would let > coprocessors inc/dec MemStore size which would mess us up). This issue is > about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19074) Miscellaneous Observer cleanups
[ https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19074: -- Status: Patch Available (was: Open) > Miscellaneous Observer cleanups > --- > > Key: HBASE-19074 > URL: https://issues.apache.org/jira/browse/HBASE-19074 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19074.master.001.patch > > > Going through Observers after fixing up MasterObserver, i see a few > violations such as Store returning a MemStoreSize instance (which would let > coprocessors inc/dec MemStore size which would mess us up). This issue is > about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19074) Miscellaneous Observer cleanups
[ https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19074: -- Attachment: HBASE-19074.master.001.patch > Miscellaneous Observer cleanups > --- > > Key: HBASE-19074 > URL: https://issues.apache.org/jira/browse/HBASE-19074 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19074.master.001.patch > > > Going through Observers after fixing up MasterObserver, i see a few > violations such as Store returning a MemStoreSize instance (which would let > coprocessors inc/dec MemStore size which would mess us up). This issue is > about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216260#comment-16216260 ] Lars Hofhansl commented on HBASE-15631: --- All good now. Thanks! > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Andrew Purtell > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, > HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19076) Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
[
https://issues.apache.org/jira/browse/HBASE-19076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Qilin Cao updated HBASE-19076:
--
Description:
After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
with the hbase-error-prone module.
{code}
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone ---
[INFO] Deleting
/home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
(min-maven-min-java-banned-xerces) @ hbase-error-prone ---
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
hbase-error-prone ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
with message:
We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{code}
was:
After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
with the hbase-error-prone module.
{panel:title=My title}
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone ---
[INFO] Deleting
/home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
(min-maven-min-java-banned-xerces) @ hbase-error-prone ---
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
hbase-error-prone ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
with message:
We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{panel}
> Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
>
>
> Key: HBASE-19076
> URL: https://issues.apache.org/jira/browse/HBASE-19076
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.0.0
>Reporter: Qilin Cao
>Assignee: Qilin Cao
>Priority: Blocker
>
> After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
> with the hbase-error-prone module.
> {code}
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone
> ---
> [INFO] Deleting
> /home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
> (min-maven-min-java-banned-xerces) @ hbase-error-prone ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
> hbase-error-prone ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19076) Ensure findbugs jsr305 jar isn't present in hbase-error-prone module
Qilin Cao created HBASE-19076:
-
Summary: Ensure findbugs jsr305 jar isn't present in
hbase-error-prone module
Key: HBASE-19076
URL: https://issues.apache.org/jira/browse/HBASE-19076
Project: HBase
Issue Type: Bug
Components: dependencies
Affects Versions: 3.0.0
Reporter: Qilin Cao
Assignee: Qilin Cao
Priority: Blocker
After HBASE-16321 ensure findbugs jsr305 jar isn't present, we have failures
with the hbase-error-prone module.
{panel:title=My title}
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ hbase-error-prone ---
[INFO] Deleting
/home/caoqilin/Codebase/github/hbase/hbase-build-support/hbase-error-prone/target
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce
(min-maven-min-java-banned-xerces) @ hbase-error-prone ---
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (banned-jsr305) @
hbase-error-prone ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
with message:
We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
{panel}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216254#comment-16216254 ] Duo Zhang commented on HBASE-19057: --- Done a rebase and force push. There are conflicts, mainly because the patches committed to master and HBASE-18410 are different for HBASE-15410. [~openinx] Please also rebase your patch, and check carefully if there are errors of what I've done to resolve conflicts. I ran TestFilterList and TestFilterListOnMini, they passed. Thanks. > Fix other code review comments about FilterList Improvement > --- > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19057-HBASE-18410.v1.patch, > HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, > HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, > HBASE-19057-HBASE-18410.v4.patch > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216251#comment-16216251
]
stack commented on HBASE-18846:
---
Thanks [~mdrob] We have issues for Replication V2. I had a bunch of comments
written all over Replication Interface but I seem to have not committed them.
Will add some here on commit.
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> HBASE-18846.master.006.patch, HBASE-18846.master.007.patch,
> HBASE-18846.master.007.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18905) Allow CPs to request flush on Region and know the completion of the requested flush
[ https://issues.apache.org/jira/browse/HBASE-18905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216242#comment-16216242 ] Anoop Sam John commented on HBASE-18905: The tracker is not some thing the core makes and pass to CPs. It is the reverse. Its kind of listener only. When Core code starts flush/compaction, we just pass Dummy objs which is a noop tracker. > Allow CPs to request flush on Region and know the completion of the requested > flush > --- > > Key: HBASE-18905 > URL: https://issues.apache.org/jira/browse/HBASE-18905 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Duo Zhang > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18905.patch > > > Follow up for HBASE-18183 > As per that Jira, we keep only requestCompaction API in Region. We did not > have any such for flush in Region. Only API which was there is a flush which > will block the callee unless flush is done. This issue has to tacke > 1. Decide whether we need a requestFlush in Region and if so add > 2. Whether the requestCompaction (And requestFlush too) should return a > Future? Right now the former do not return any but allow to pass a > CompactionLifeCycleTracker which will get notified on start and end of > compaction. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17852: -- Fix Version/s: (was: 2.0.0-alpha-4) 2.0.0-beta-1 > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216239#comment-16216239 ] stack commented on HBASE-17852: --- bq.. stack, would you prefer I hold off and re-tag this for beta-1? Yeah. Sounds like an RPC from a CP to a remote table. This is problematic (apart from yet-another-system-table though already a backup system table). Presumes remote table always up and ready, already-assigned and recovered ahead of the RPC. We have no means of guaranteeing this (This issue has 'fault-tolerance' in its summary). Thanks. > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216240#comment-16216240 ] stack commented on HBASE-17852: --- I moved it [~elserj] Thanks. > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216236#comment-16216236 ] Ted Yu commented on HBASE-17852: bq. Ted Yu has more depth to provide some more context Unfortunately I don't. Hence the request for unit test showing the scenario. > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216221#comment-16216221 ] Duo Zhang commented on HBASE-19057: --- OK, let me rebase first. > Fix other code review comments about FilterList Improvement > --- > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19057-HBASE-18410.v1.patch, > HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, > HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, > HBASE-19057-HBASE-18410.v4.patch > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[
https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216220#comment-16216220
]
Josh Elser commented on HBASE-17852:
bq. On looking at the patch, it looks like we have a backup system table and
then a whole new table for bulk loaded materials. A whole system table just for
bulk loaded files?
Yeah, as I recall, Vlad ran into a case where, when trying to make sure that we
didn't lose files in incremental backups, we grabbed a table-level lock.
Because this lock was on the {{hbase:backup}} table, it introduced a situation
where the system deadlocked. By introducing a table which is explicitly
tracking the bulk-loaded files, it avoids this deadlock scenario.
bq. Whats going on in here? Is it written up anywhere? Are we implementing our
own transaction management as the below comment would suggest?
My understanding is that, functionality-wise, we're not actually changing
anything. This is really just automatically deploying the BackupObserver
instead of forcing it to be deployed automatically.
I'm not sure if [~tedyu] has more depth to provide some more context. I do know
that Vlad is traveling for familial reasons this week and is likely slow to
respond.
[~stack], would you prefer I hold off and re-tag this for beta-1?
> Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental
> backup)
>
>
> Key: HBASE-17852
> URL: https://issues.apache.org/jira/browse/HBASE-17852
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch,
> HBASE-17852-v3.patch, HBASE-17852-v4.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18873: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18873.001.branch-2.patch, > HBASE-18873.002.branch-2.patch, HBASE-18873.003.branch-2.patch > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19069) Do not wrap the original CompactionLifeCycleTracker when calling CP hooks
[ https://issues.apache.org/jira/browse/HBASE-19069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216212#comment-16216212 ] Duo Zhang commented on HBASE-19069: --- Let me finish this. Thanks [~stack] for reviewing. > Do not wrap the original CompactionLifeCycleTracker when calling CP hooks > - > > Key: HBASE-19069 > URL: https://issues.apache.org/jira/browse/HBASE-19069 > Project: HBase > Issue Type: Sub-task > Components: Compaction, Coprocessors >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19069.patch, HBASE-19069.patch > > > My fault... > The UT added in HBASE-18989 does not follow the new rule so the CP is not > loaded actually... When fixed the UT fails... > The reason is that I use a wrapped CompactionLifeCycleTracker for > implementing CompactionLifeCycleTracker. Obviously this is not the correct > approach as we need to pass the original one to CP hooks... > Let me fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18873: --- Release Note: GlobalQuotaSettings was introduced to avoid protocol-specific Java classes from leaking into API which is users may leverage. This class has a number of methods which return plain-Java-objects instead of these protocol-specific classes in an effort to better provide stability in the future. > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18873.001.branch-2.patch, > HBASE-18873.002.branch-2.patch, HBASE-18873.003.branch-2.patch > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[
https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216210#comment-16216210
]
stack commented on HBASE-17852:
---
Whats going on in here? Is it written up anywhere? Are we implementing our own
transaction management as the below comment would suggest?
{code}
Some notes after initial analysis of implementation of bulk-loaded files support
RegionObserver coprocessor has pre-commit and post-commit code (kind of Tx),
but only on a region level. No Tx support on a table level. This means that if
(for some regions), loading files fail, we will be left with a partial data in
both: table store physical location and in backup system table. What we need
here is Tx support for the whole bulk load operation cluster-wide (prepare,
commit). And hooks exposed for custom coprocessor (Master?).
What will happen if bulk load operation runs at the same time as incremental
backup? Backup will see partial updates, but it should not.
We add files to backup system tables, but I have not found where and when we
delete those files.
{code}
I saw above note but no more since
On looking at the patch, it looks like we have a backup system table and then a
whole new table for bulk loaded materials. A whole system table just for bulk
loaded files?
> Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental
> backup)
>
>
> Key: HBASE-17852
> URL: https://issues.apache.org/jira/browse/HBASE-17852
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch,
> HBASE-17852-v3.patch, HBASE-17852-v4.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19072:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-alpha-4
1.2.7
1.5.0
1.3.2
1.4.0
Status: Resolved (was: Patch Available)
Thanks for the review, Jerry.
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-4
>
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19072) Missing break in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19072:
---
Summary: Missing break in catch block of InterruptedException in
HRegion#waitForFlushes() (was: Missing beak in catch block of
InterruptedException in HRegion#waitForFlushes() )
> Missing break in catch block of InterruptedException in
> HRegion#waitForFlushes()
> -
>
> Key: HBASE-19072
> URL: https://issues.apache.org/jira/browse/HBASE-19072
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 19072.v1.txt
>
>
> During review of HBASE-18358, [~elserj] found that there was missing break in
> the catch block:
> {code}
> } catch (InterruptedException iex) {
> // essentially ignore and propagate the interrupt back up
> LOG.warn("Interrupted while waiting");
> interrupted = true;
> }
> {code}
> When thread is interrupted, we shouldn't wait on writestate.flushing anymore.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216203#comment-16216203 ] Andrew Purtell commented on HBASE-15631: Ah, no, I picked from branch-1.4 to branch-1 without committing an update to hbase-rsgroup/pom.xml. Pushed an addendum to fix it. > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Andrew Purtell > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, > HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params
[
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19048:
--
Hadoop Flags: Reviewed
Status: Patch Available (was: Open)
> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch
>
>
> These are the ones in MasterObserver
> {code}
> preAbortProcedure- ProcedureExecutor
> postGetProcedures- Procedure
> postGetLocks - LockedResource
> preRequestLock - LockType
> postRequestLock - LockType
> preLockHeartbeat - LockProcedure
> postLockHeartbeat- LockProcedure
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19053) Split out o.a.h.h.http from hbase-server into a separate module
[
https://issues.apache.org/jira/browse/HBASE-19053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216199#comment-16216199
]
Hadoop QA commented on HBASE-19053:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 41 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 8m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
39s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
8s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
12s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 38s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}102m 7s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}188m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19053 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893601/HBASE-19053.master.004.patch
|
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml
[jira] [Commented] (HBASE-14093) deduplicate copies of bootstrap files
[
https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216192#comment-16216192
]
Mike Drob commented on HBASE-14093:
---
Patch applies well and runs well on master, but when I cherry-pick to branch-2,
I get the following error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.0.1:unpack
(unpack-bootstrap) on project hbase-static-web-resources: Unable to find
artifact version of org.webjars:bootstrap in either dependency list or in
project's dependency management. -> [Help 1]
{noformat}
Any ideas where this comes from?
> deduplicate copies of bootstrap files
> -
>
> Key: HBASE-14093
> URL: https://issues.apache.org/jira/browse/HBASE-14093
> Project: HBase
> Issue Type: Improvement
> Components: build
>Reporter: Sean Busbey
>Assignee: Tamas Penzes
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-14093.master.001.patch,
> HBASE-14093.master.002.patch, HBASE-14093.master.002.patch,
> HBASE-14093.master.003.patch, HBASE-14093.master.003.patch,
> HBASE-14093.master.004.patch, direct_extract.log, indirect_extract.log,
> patch-shadedjars.txt
>
>
> right now we have a couple of different copies of the bootstrap js and css
> files. It'll be easier to maintain them later if we can centralize.
> Move them to a common location and use maven to populate them as needed in
> various component build directories.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19075) Task tabs on master UI cause page scroll
[
https://issues.apache.org/jira/browse/HBASE-19075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-19075:
--
Description:
On the master info page, the clicking the tabs under Tasks causes the page to
scroll back to the top of the page.
{noformat}
Tasks
Show All Monitored Tasks Show non-RPC Tasks Show All RPC Handler Tasks Show
Active RPC Calls Show Client Operations View as JSON
{noformat}
^^ Any of those
The other tab-like links on the page keep the scroll in the same location.
was:
On the master info page, the clicking the tabs under Tasks causes the page to
scroll back to the top of the page.
{noformat}
Tasks
Show All Monitored Tasks Show non-RPC Tasks Show All RPC Handler Tasks Show
Active RPC Calls Show Client Operations View as JSON
{noformat}
^^ Any of those
> Task tabs on master UI cause page scroll
>
>
> Key: HBASE-19075
> URL: https://issues.apache.org/jira/browse/HBASE-19075
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Mike Drob
> Labels: beginner
> Fix For: 2.0.0
>
>
> On the master info page, the clicking the tabs under Tasks causes the page to
> scroll back to the top of the page.
> {noformat}
> Tasks
> Show All Monitored Tasks Show non-RPC Tasks Show All RPC Handler Tasks Show
> Active RPC Calls Show Client Operations View as JSON
> {noformat}
> ^^ Any of those
> The other tab-like links on the page keep the scroll in the same location.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19075) Task tabs on master UI cause page scroll
[
https://issues.apache.org/jira/browse/HBASE-19075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-19075:
--
Fix Version/s: 2.0.0
> Task tabs on master UI cause page scroll
>
>
> Key: HBASE-19075
> URL: https://issues.apache.org/jira/browse/HBASE-19075
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Mike Drob
> Labels: beginner
> Fix For: 2.0.0
>
>
> On the master info page, the clicking the tabs under Tasks causes the page to
> scroll back to the top of the page.
> {noformat}
> Tasks
> Show All Monitored Tasks Show non-RPC Tasks Show All RPC Handler Tasks Show
> Active RPC Calls Show Client Operations View as JSON
> {noformat}
> ^^ Any of those
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19075) Task tabs on master UI cause page scroll
Mike Drob created HBASE-19075:
-
Summary: Task tabs on master UI cause page scroll
Key: HBASE-19075
URL: https://issues.apache.org/jira/browse/HBASE-19075
Project: HBase
Issue Type: Bug
Components: master
Reporter: Mike Drob
On the master info page, the clicking the tabs under Tasks causes the page to
scroll back to the top of the page.
{noformat}
Tasks
Show All Monitored Tasks Show non-RPC Tasks Show All RPC Handler Tasks Show
Active RPC Calls Show Client Operations View as JSON
{noformat}
^^ Any of those
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19075) Task tabs on master UI cause page scroll
[
https://issues.apache.org/jira/browse/HBASE-19075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-19075:
--
Labels: beginner (was: )
> Task tabs on master UI cause page scroll
>
>
> Key: HBASE-19075
> URL: https://issues.apache.org/jira/browse/HBASE-19075
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Mike Drob
> Labels: beginner
> Fix For: 2.0.0
>
>
> On the master info page, the clicking the tabs under Tasks causes the page to
> scroll back to the top of the page.
> {noformat}
> Tasks
> Show All Monitored Tasks Show non-RPC Tasks Show All RPC Handler Tasks Show
> Active RPC Calls Show Client Operations View as JSON
> {noformat}
> ^^ Any of those
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-16290) Dump summary of callQueue content; can help debugging
[ https://issues.apache.org/jira/browse/HBASE-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreeram Venkatasubramanian updated HBASE-16290: --- Attachment: HBASE-16290.master.008.patch > Dump summary of callQueue content; can help debugging > - > > Key: HBASE-16290 > URL: https://issues.apache.org/jira/browse/HBASE-16290 > Project: HBase > Issue Type: Bug > Components: Operability >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Sreeram Venkatasubramanian > Labels: beginner > Fix For: 2.0.0 > > Attachments: DebugDump_screenshot.png, HBASE-16290.master.001.patch, > HBASE-16290.master.002.patch, HBASE-16290.master.003.patch, > HBASE-16290.master.004.patch, HBASE-16290.master.005.patch, > HBASE-16290.master.006.patch, HBASE-16290.master.007.patch, > HBASE-16290.master.008.patch, Sample Summary.txt > > > Being able to get a clue what is in a backedup callQueue could give insight > on what is going on on a jacked server. Just needs to summarize count, sizes, > call types. Useful debugging. In a servlet? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216182#comment-16216182
]
Lars Hofhansl commented on HBASE-15631:
---
Hmm...
{code}
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for
org.apache.hbase:hbase-rsgroup:[unknown-version]: Could not find artifact
org.apache.hbase:hbase:pom:1.4.0-SNAPSHOT and 'parent.relativePath' points at
wrong local POM @ line 24, column 11
[WARNING] 'build.plugins.plugin.version' for
org.codehaus.mojo:exec-maven-plugin is missing. @
org.apache.hbase:hbase-shaded-check-invariants:[unknown-version],
/home/lars/dev/hbase-1/hbase-shaded/hbase-shaded-check-invariants/pom.xml, line
161, column 15
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.hbase:hbase-rsgroup:[unknown-version]
(/home/lars/dev/hbase-1/hbase-rsgroup/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for
org.apache.hbase:hbase-rsgroup:[unknown-version]: Could not find artifact
org.apache.hbase:hbase:pom:1.4.0-SNAPSHOT and 'parent.relativePath' points at
wrong local POM @ line 24, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{code}
Something in my env?
> Backport Regionserver Groups (HBASE-6721) to branch-1
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch,
> HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an
> issue as it does not: 1. destabilize the code. 2. cause backward
> incompatibility.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216177#comment-16216177
]
Mike Drob commented on HBASE-18846:
---
Yea, pretty good as a first cut, glad we will have time until beta1 to make
refinements.
{noformat}
+// TODO: I can't follow replication; it has initialize and then later on
we start it!
{noformat}
I don't like this, if you can't follow it, what chance do I have? Let's file a
follow on JIRA for the replication cleanup that needs to happen - I'm worried
that we're just getting the tip of the iceberg here.
{code}
+return new org.apache.hadoop.hbase.shaded.com.google.common.collect.
+
ImmutableList.Builder().addAll(bssi).build();
{code}
Why not {{return Collections.unmodifiableList(bssi);}}
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> HBASE-18846.master.006.patch, HBASE-18846.master.007.patch,
> HBASE-18846.master.007.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216179#comment-16216179
]
Mike Drob commented on HBASE-18846:
---
+1 to get this in, above comment doesn't really matter.
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> HBASE-18846.master.006.patch, HBASE-18846.master.007.patch,
> HBASE-18846.master.007.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18893) Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using ModifyTableProcedure
[ https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-18893: -- Resolution: Fixed Fix Version/s: 3.0.0 Status: Resolved (was: Patch Available) > Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using > ModifyTableProcedure > > > Key: HBASE-18893 > URL: https://issues.apache.org/jira/browse/HBASE-18893 > Project: HBase > Issue Type: Bug > Components: Coprocessors, master >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: HBASE-18893.patch, HBASE-18893.v2.patch, > HBASE-18893.v3.patch, HBASE-18893.v4.patch > > > The shell changed from using separate add/modify/delete column calls to > funneling everything through modify table for performance reasons. We know > that using modify table works for everything. Let's drop the old code for > Add/Modify/Delete Column so that we have a lower maintenance burden and fewer > code paths to reason about. > Was: shell 'alter' command no longer distinguishes column > add/modify/delete > After HBASE-15641 all 'alter' commands go through a single modifyTable call > at the end, so we no longer can easily distinguish add, modify, and delete > column events. This potentially affects coprocessors that needed the update > notifications for new or removed columns. > Let's let the shell still make separate behaviour calls like it did before > without undoing the batching that seems pretty useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch-1 and branch-1.4 > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Andrew Purtell > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, > HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Attachment: HBASE-15631-branch-1.patch Attaching final patch version * Shell and shell test fixes * Move all dependencies and test file inclusion into profiles in all modules > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Andrew Purtell > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, > HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18601) Update Htrace to 4.2
[
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216155#comment-16216155
]
Hadoop QA commented on HBASE-18601:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
33s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 10m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
6s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
4s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
1s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
27s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
1s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
34m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 13m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
36s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}101m 45s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}220m 48s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
[jira] [Created] (HBASE-19074) Miscellaneous Observer cleanups
stack created HBASE-19074: - Summary: Miscellaneous Observer cleanups Key: HBASE-19074 URL: https://issues.apache.org/jira/browse/HBASE-19074 Project: HBase Issue Type: Sub-task Components: Coprocessors Reporter: stack Assignee: stack Fix For: 2.0.0-alpha-4 Going through Observers after fixing up MasterObserver, i see a few violations such as Store returning a MemStoreSize instance (which would let coprocessors inc/dec MemStore size which would mess us up). This issue is about cleaning these remainders up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-18410: - Hadoop Flags: Incompatible change Release Note: In this task, we fixed all existing bugs in FilterList, and did the code refactor which ensured interface compatibility . we divided the FilterList into two separated sub-classes: FilterListWithOR and FilterListWithAND, The FilterListWithOR has been optimised to choose the next minimal step to seek cell rather than SKIP cell one by one, and the FilterListWithAND has been optimised to choose the next maximal key to seek among sub-filters in filter list. All in all, The code in FilterList is clean and easier to follow now. Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in current family, not to next row in all family. it’s more reasonable, because ReturnCode is a concept in store level, not in region level. > FilterList Improvement. > - > > Key: HBASE-18410 > URL: https://issues.apache.org/jira/browse/HBASE-18410 > Project: HBase > Issue Type: Umbrella > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-alpha-4 > > > FilterList.java is complex now, and we have found some improvements for it. > So create an issue to address it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19065) HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish
[
https://issues.apache.org/jira/browse/HBASE-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216110#comment-16216110
]
Ted Yu commented on HBASE-19065:
I ran \*LoadIncrementalHFiles\* locally with patch v2 which passed.
> HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish
>
>
> Key: HBASE-19065
> URL: https://issues.apache.org/jira/browse/HBASE-19065
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 19065.v1.txt, 19065.v2.txt
>
>
> When I was debugging bulk load failure, I saw the following in region server
> log:
> {code}
> 2017-10-17 23:05:28,795 DEBUG
> [B.defaultRpcServer.handler=0,queue=0,port=16020] regionserver.HRegion: NOT
> flushing memstore for region mx_,
> f449669a8b0341e4edbd2ebdacc72094f449669a8b0341e4edbd2ebdacc7209420150711,1504909319142.52d496ba39036e0c2cc9522895ad438f.,
> flushing=true, writesEnabled=true
> 2017-10-17 23:05:28,796 ERROR
> [B.defaultRpcServer.handler=0,queue=0,port=16020]
> access.SecureBulkLoadEndpoint: Failed to complete bulk load
> java.io.IOException: Could not bulk load with an assigned sequential ID
> because the flush didn't run. Reason for not flushing: Not flushing since
> already flushing
> at
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:5282)
> at
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:292)
> at
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:275)
> {code}
> There was concurrent flush which got misinterpreted by bulkLoadHFiles().
> HRegion#bulkLoadHFiles() should wait for the concurrent flush to complete.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19057) Fix other code review comments about FilterList Improvement
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-19057: - Attachment: HBASE-19057-HBASE-18410.v4.patch > Fix other code review comments about FilterList Improvement > --- > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19057-HBASE-18410.v1.patch, > HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, > HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, > HBASE-19057-HBASE-18410.v4.patch > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19072) Missing beak in catch block of InterruptedException in HRegion#waitForFlushes()
[
https://issues.apache.org/jira/browse/HBASE-19072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216100#comment-16216100
]
Hadoop QA commented on HBASE-19072:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 16m
2s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.4.0/precommit-patchnames for
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
24s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
51m 9s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}118m
52s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}214m 36s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19072 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893583/19072.v1.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 1fe6da60d86e 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 880b26d |
| Default Java | 1.8.0_141 |
| findbugs | v3.1.0-RC3 |
| Test Results |
[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement
[
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216076#comment-16216076
]
Hadoop QA commented on HBASE-19057:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
37s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
5s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
46s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
46s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
23s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
37s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
55s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
10s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
30s{color} | {color:green} HBASE-18410 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
54s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
37m 55s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
33s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 71m 15s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}153m
13s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
55s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} |
[jira] [Commented] (HBASE-19065) HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish
[
https://issues.apache.org/jira/browse/HBASE-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216071#comment-16216071
]
Hadoop QA commented on HBASE-19065:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.4.0/precommit-patchnames for
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
52s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 19s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}133m 33s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}191m 56s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19065 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893586/19065.v2.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 38b03431f727 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 880b26d |
| Default Java | 1.8.0_141 |
| findbugs | v3.1.0-RC3 |
| unit |
[jira] [Updated] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17852: --- Fix Version/s: (was: 2.0.0-beta-1) 2.0.0-alpha-4 > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216044#comment-16216044 ] Josh Elser commented on HBASE-17852: Thanks, Ted. FYI, [~stack], will be landing this on in alpha-4 tonight as well if it concerns you at all. > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-17852-v1.patch, HBASE-17852-v2.patch, > HBASE-17852-v3.patch, HBASE-17852-v4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19073) Cleanup CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19073: - Status: Patch Available (was: Open) > Cleanup CoordinatedStateManager > --- > > Key: HBASE-19073 > URL: https://issues.apache.org/jira/browse/HBASE-19073 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-19073.master.001.patch > > > - Remove the configuration hbase.coordinated.state.manager.class > - Keep following interface since they nicely separate ZK based > implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination, > ProcedureCoordinatorRpcs, ProcedureMemberRpcs > - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single > CSM interface. > - Don't pass whole CSM object around (with server in it which gives acess to > pretty much everything), only pass the relevant dependencies. > Discussion thread on dev@ mailing list. > http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19073) Cleanup CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19073: - Attachment: (was: HBASE-19073.master.001.patch) > Cleanup CoordinatedStateManager > --- > > Key: HBASE-19073 > URL: https://issues.apache.org/jira/browse/HBASE-19073 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-19073.master.001.patch > > > - Remove the configuration hbase.coordinated.state.manager.class > - Keep following interface since they nicely separate ZK based > implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination, > ProcedureCoordinatorRpcs, ProcedureMemberRpcs > - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single > CSM interface. > - Don't pass whole CSM object around (with server in it which gives acess to > pretty much everything), only pass the relevant dependencies. > Discussion thread on dev@ mailing list. > http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19073) Cleanup CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19073: - Attachment: HBASE-19073.master.001.patch > Cleanup CoordinatedStateManager > --- > > Key: HBASE-19073 > URL: https://issues.apache.org/jira/browse/HBASE-19073 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-19073.master.001.patch > > > - Remove the configuration hbase.coordinated.state.manager.class > - Keep following interface since they nicely separate ZK based > implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination, > ProcedureCoordinatorRpcs, ProcedureMemberRpcs > - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single > CSM interface. > - Don't pass whole CSM object around (with server in it which gives acess to > pretty much everything), only pass the relevant dependencies. > Discussion thread on dev@ mailing list. > http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216019#comment-16216019
]
Hadoop QA commented on HBASE-16338:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 25m
48s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
8s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 17 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
36s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
43s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
27s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
11s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m
2s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
57s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
53s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
19s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
4s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
2s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
11s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 29s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
40s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}126m 41s{color}
| {color:red} root in the
[jira] [Updated] (HBASE-19073) Cleanup CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19073: - Attachment: HBASE-19073.master.001.patch > Cleanup CoordinatedStateManager > --- > > Key: HBASE-19073 > URL: https://issues.apache.org/jira/browse/HBASE-19073 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-19073.master.001.patch > > > - Remove the configuration hbase.coordinated.state.manager.class > - Keep following interface since they nicely separate ZK based > implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination, > ProcedureCoordinatorRpcs, ProcedureMemberRpcs > - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single > CSM interface. > - Don't pass whole CSM object around (with server in it which gives acess to > pretty much everything), only pass the relevant dependencies. > Discussion thread on dev@ mailing list. > http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
