date:20150202


[ 
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301834#comment-14301834
 ] 

Hadoop QA commented on HBASE-12035:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12695958/HBASE-12035.patch
  against master branch at commit fef78acf6534f6736c10d2054cf8cb479edd3291.
  ATTACHMENT ID: 12695958

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 39 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+  public static TableState parseFrom(TableName tableName, byte[] bytes) 
throws DeserializationException {
+
((FSTableDescriptors)(masterServices.getTableDescriptors())).createTableDescriptorForTableDirectory(
+  WRONG_USAGE, EMPTY_META_CELL, EXPIRED_TABLE_LOCK, BOUNDARIES_ERROR, 
ORPHAN_TABLE_STATE, NO_TABLE_STATE

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.client.TestReplicaWithCluster

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s):   
at 
org.apache.hadoop.hbase.master.TestMasterOperationsForRegionReplicas.testCreateTableWithMultipleReplicas(TestMasterOperationsForRegionReplicas.java:206)

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12669//console

This message is automatically generated.

 Client does an RPC to master everytime a region is relocated
 

 Key: HBASE-12035
 URL: https://issues.apache.org/jira/browse/HBASE-12035
 Project: HBase
  Issue Type: Improvement
  Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
 Fix For: 2.0.0

 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch


 HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of

[jira] [Commented] (HBASE-12452) Add regular expression based split policy

[
https://issues.apache.org/jira/browse/HBASE-12452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301916#comment-14301916
]

Hadoop QA commented on HBASE-12452:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12695975/HBASE-12452-V2.patch
against master branch at commit fef78acf6534f6736c10d2054cf8cb479edd3291.
ATTACHMENT ID: 12695975

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:red}-1 checkstyle{color}. The applied patch generated
1938 checkstyle errors (more than the master's current 1936 errors).

{color:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 2.0.3) warnings.

{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}. The patch passed unit tests in .

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/patchReleaseAuditWarnings.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//artifact/patchprocess/checkstyle-aggregate.html

Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12670//console

This message is automatically generated.

Add regular expression based split policy
-

Key: HBASE-12452
URL: https://issues.apache.org/jira/browse/HBASE-12452
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: He Liangliang
Assignee: He Liangliang
Priority: Minor
Attachments: HBASE-12452-V2.patch, HBASE-12452-V2.patch,
HBASE-12452.patch

The current DelimitedKeyPrefixRegionSplitPolicy split policy is not flexible
enough to describe the split point prefix in some case. A regex based split
policy is proposed, for example:
^[^\x00]+\x00[^\x00]+\x00
means the split point will always be truncated to a prefix at the second \0
char.
The binary string support is quite useful when the rowkey encoded by a common
data access library instead of concatenated manually by application developer.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12439) Procedure V2

[
https://issues.apache.org/jira/browse/HBASE-12439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301960#comment-14301960
]

stack commented on HBASE-12439:
---

bq. No, Procedure is the internal name for I'm doing something.

Its confusing swapping in Operation for Procedure when you've done all this
work talking up Procedures and of how Procedures are made of zero or more
Sub-Procedures.

Ok on the rest [~mbertozzi] Looks great.

Procedure V2

Key: HBASE-12439
URL: https://issues.apache.org/jira/browse/HBASE-12439
Project: HBase
Issue Type: New Feature
Components: master
Affects Versions: 2.0.0
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
Priority: Minor
Attachments: ProcedureV2.pdf, Procedurev2Notification-Bus.pdf

Procedure v2 (aka Notification Bus) aims to provide a unified way to build:
* multi-steps procedure with a rollback/rollforward ability in case of
failure (e.g. create/delete table)
** HBASE-12070
* notifications across multiple machines (e.g. ACLs/Labels/Quotas cache
updates)
** Make sure that every machine has the grant/revoke/label
** Enforce space limit quota across the namespace
** HBASE-10295 eliminate permanent replication zk node
* procedures across multiple machines (e.g. Snapshots)
* coordinated long-running procedures (e.g. compactions, splits, ...)
* Synchronous calls, with the ability to see the state/result in case of
failure.
** HBASE-11608 sync split
still work in progress/initial prototype: https://reviews.apache.org/r/27703/

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12955) Make ITBLL less of a wuss


[ 
https://issues.apache.org/jira/browse/HBASE-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301978#comment-14301978
 ] 

stack commented on HBASE-12955:
---

Ok. Let me make new patch.

I enabled splitting and the 1B still worked (though only 4 splits happened).

 Make ITBLL less of a wuss
 -

 Key: HBASE-12955
 URL: https://issues.apache.org/jira/browse/HBASE-12955
 Project: HBase
  Issue Type: Task
Reporter: stack
Assignee: stack

 ITBLL avoids rolling restart and kill of the server hosting meta by default.
 {code}
  Action[] actions1 = new Action[] {
 -new RestartRandomRsExceptMetaAction(6),
 +new RestartRandomRsAction(6),
  new RestartActiveMasterAction(5000),
 -new RollingBatchRestartRsExceptMetaAction(5000, 1.0f, 2), //only 
 allow 2 servers to be dead
 +new RollingBatchRestartRsAction(5000, 1.0f, 2), //only allow 2 
 servers to be dead
  new ForceBalancerAction()
 {code}
 Enable killing of meta.
 Running tests over the w/e against 1.0, all seems to work w/ this enabled 
 (splits were disabled).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts


[ 
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302031#comment-14302031
 ] 

Andrew Purtell commented on HBASE-12954:


No

 Ability impaired using HBase on multihomed hosts
 

 Key: HBASE-12954
 URL: https://issues.apache.org/jira/browse/HBASE-12954
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.4
Reporter: Clay B.
Assignee: Ted Yu
Priority: Minor
 Attachments: 12954-v1.txt, Hadoop Three Interfaces.png


 For HBase clusters running on unusual networks (such as NAT'd cloud 
 environments or physical machines with multiple IP's per network interface) 
 it would be ideal to have a way to both specify:
 # which IP interface to which HBase master or region-server will bind
 # what hostname HBase will advertise in Zookeeper both for a master or 
 region-server process
 While efforts such as HBASE-8640 go a long way to normalize these two sources 
 of information, it is not possible in the current design of the properties 
 available to an administrator for these to be unambiguously specified.
 One has been able to request {{hbase.master.ipc.address}} or 
 {{hbase.regionserver.ipc.address}} but one can not specify the desired HBase 
 {{hbase.master.hostname}}. (It was removed in HBASE-1357, further I am 
 unaware of a region-server equivalent.)
 I use a configuration management system to generate all of my configuration 
 files on a per-machine basis. As such, an option to generate a file 
 specifying exactly which hostname to use would be helpful.
 Today, specifying the bind address for HBase works and one can use an 
 HBase-only DNS for faking what to put in Zookeeper but this is far from 
 ideal. Network interfaces have no intrinsic IP address, nor hostname. 
 Specifing a DNS server is awkward as the DNS server may differ from the 
 system's resolver and is a single IP address. Similarly, on hosts which use a 
 transient VIP (e.g. through keepalived) for other services, it means there's 
 a seemingly non-deterministic hostname choice made by HBase depending on the 
 state of the VIP at daemon start-up time.
 I will attach two networking examples I use which become very difficult to 
 manage under the current properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12439) Procedure V2

2015-02-02 Thread Matteo Bertozzi (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301894#comment-14301894
]

Matteo Bertozzi commented on HBASE-12439:
-

{quote}The API is Admin.doOperation(). Should it be Admin.doProcedure? (In
doc., you start talking about 'operations' when you were talking about
'procedures' up to this).{quote}
No, Procedure is the internal name for I'm doing something.
Example: delete table maps to a procedure but snapshot may map to multiple
procedures (depending on how you view the execution it may be the master part +
the RS subprocs or it may be just the snapshot namespace with the table
snapshots as subprocedures).
another example is create table, if you see create table operation as create
procedure + assignment procedure. more in general I use operation because
there may be more work than just call the procedure.

{quote}If the master does not receve a response within a timeout, or the
region was reassigned, it will resend the execution request., master will just
retry for ever?{quote}
It depends, e.g. if the procedure is assignment yes. if the procedure is
snapshot it will timeout after Nsec.

{quote}For the TwoPhaseProcedure, would be good to draw out the steps as you
have done for the OnePhaseProcedure procedure. Would help me figure if I get
how this 'staging' stuff works.{quote}
sure, still in progress

{quote}What is this? (The syncclient implementation can be done for the 2.0
branch, but we can’t backport that to
keep the compatibility. New client methods can be added using the
procedure){quote}
our Admin is not really sync, for example create table and similar depends on
the order of the operation master-side. so if you change the code of the
handler but not the client, the client will be async since the operation server
side may not be completed.
With the procedure you are waiting on the proc to be completed, so you can
change the server side as much as you want and the client don't care about it.
and you also get the master failover for free. e.g. In the middle of Create
Table the master goes down, the client is spinning on isDone(createProcId) the
backup master complete the create table and the client receive the isDone() =
true.

Procedure V2

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

2015-02-02 Thread Clay B. (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301948#comment-14301948
]

Clay B. commented on HBASE-12954:
-

Hi Andrew Purtell, indeed this can happen under my networks:

One could -- intentionally -- have an apparent mismatch of IP and hostname. In
the case of the OpenStack network, a region server may talk to a master on the
same private (tenancy) network -- all traffic would go via the 100.127.1.0/24.
But for external clients to be able to talk in, Zookeeper would be advertising
the {{*.tenant.openstack.example.com}} DNS names (192.168.101.0/24 network).
The master should always be able to reach the regionserver on the IP the
regionserver is bound to {{hbase.regionserver.ipc.address}}, but what is
advertised in Zookeeper may be different than what the master would reverse-DNS
lookup for the regionserver's bound IP address.

Conversely, what is advertised in Zookeeper should always reach the
regionserver from anywhere in my networks (e.g. an external client or the
master).

Ability impaired using HBase on multihomed hosts

Key: HBASE-12954
URL: https://issues.apache.org/jira/browse/HBASE-12954
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.4
Reporter: Clay B.
Assignee: Ted Yu
Priority: Minor
Attachments: 12954-v1.txt, Hadoop Three Interfaces.png

For HBase clusters running on unusual networks (such as NAT'd cloud
environments or physical machines with multiple IP's per network interface)
it would be ideal to have a way to both specify:
# which IP interface to which HBase master or region-server will bind
# what hostname HBase will advertise in Zookeeper both for a master or
region-server process
While efforts such as HBASE-8640 go a long way to normalize these two sources
of information, it is not possible in the current design of the properties
available to an administrator for these to be unambiguously specified.
One has been able to request {{hbase.master.ipc.address}} or
{{hbase.regionserver.ipc.address}} but one can not specify the desired HBase
{{hbase.master.hostname}}. (It was removed in HBASE-1357, further I am
unaware of a region-server equivalent.)
I use a configuration management system to generate all of my configuration
files on a per-machine basis. As such, an option to generate a file
specifying exactly which hostname to use would be helpful.
Today, specifying the bind address for HBase works and one can use an
HBase-only DNS for faking what to put in Zookeeper but this is far from
ideal. Network interfaces have no intrinsic IP address, nor hostname.
Specifing a DNS server is awkward as the DNS server may differ from the
system's resolver and is a single IP address. Similarly, on hosts which use a
transient VIP (e.g. through keepalived) for other services, it means there's
a seemingly non-deterministic hostname choice made by HBase depending on the
state of the VIP at daemon start-up time.
I will attach two networking examples I use which become very difficult to
manage under the current properties.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12952) Seek with prefixtree may hang


 [ 
https://issues.apache.org/jira/browse/HBASE-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-12952:
---
Fix Version/s: (was: 0.98.6.1)
   0.98.11
   1.1.0
   1.0.1
   2.0.0

 Seek with prefixtree may hang
 -

 Key: HBASE-12952
 URL: https://issues.apache.org/jira/browse/HBASE-12952
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 1.0.0, 0.98.7, 0.98.8, 0.98.6.1, 0.98.9, 0.98.10
Reporter: sinfox
 Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.11

 Attachments: hbase_0.98.6.1.patch


 I have upgraded my hbase cluster from hbase-0.96 to hbase-0.98.6.1,then i 
 found some compaction hang on many regionserver, and the cpu costed100%.
 It looks like there is an infinite loop somewhere. 
 From the log, i found StoreFileScanner.java : reseekAtOrAfter(HFileScanner s, 
 KeyValue k) enterd an infinite loop.
 Read source code, I found en error on PrefixTreeArrayReversibleScanner.java : 
 previousRowInternal()
 eg:  
   A:fan:12, numCell:1
   A : 1  - B
   A : 2  - C
   
   C: 3  - D
   C: 4  - E
   
 A: fan:12, numCell:1
 B: fan,numCell:1
 C: fan:34,numCell: 0
 D: fan,numCell:1
 E: fan,numCell:1
 when currentNode is D, its previous node is B , but this function will return 
 A.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12955) Make ITBLL less of a wuss


[ 
https://issues.apache.org/jira/browse/HBASE-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301794#comment-14301794
 ] 

stack commented on HBASE-12955:
---

bq. Are you talking about the serverKilling monkey? It's purpose was to not 
kill the meta. 

Yes. Why not kill meta?

 Make ITBLL less of a wuss
 -

 Key: HBASE-12955
 URL: https://issues.apache.org/jira/browse/HBASE-12955
 Project: HBase
  Issue Type: Task
Reporter: stack
Assignee: stack

 ITBLL avoids rolling restart and kill of the server hosting meta by default.
 {code}
  Action[] actions1 = new Action[] {
 -new RestartRandomRsExceptMetaAction(6),
 +new RestartRandomRsAction(6),
  new RestartActiveMasterAction(5000),
 -new RollingBatchRestartRsExceptMetaAction(5000, 1.0f, 2), //only 
 allow 2 servers to be dead
 +new RollingBatchRestartRsAction(5000, 1.0f, 2), //only allow 2 
 servers to be dead
  new ForceBalancerAction()
 {code}
 Enable killing of meta.
 Running tests over the w/e against 1.0, all seems to work w/ this enabled 
 (splits were disabled).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-10942) support parallel request cancellation for multi-get

2015-02-02 Thread Nicolas Liochon (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302028#comment-14302028
 ] 

Nicolas Liochon commented on HBASE-10942:
-

Time goes by ;-)
LGTM, +1

 support parallel request cancellation for multi-get
 ---

 Key: HBASE-10942
 URL: https://issues.apache.org/jira/browse/HBASE-10942
 Project: HBase
  Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Nicolas Liochon
 Fix For: hbase-10070

 Attachments: 10942-1.1.txt, 10942-for-98.zip, 10942.patch, 
 HBASE-10942.01.patch, HBASE-10942.02.patch, HBASE-10942.patch






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12955) Make ITBLL less of a wuss


[ 
https://issues.apache.org/jira/browse/HBASE-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301826#comment-14301826
 ] 

Enis Soztutar commented on HBASE-12955:
---

We have done that monkey in HBASE-10572 as a part of the IT for region 
replicas. The test IntegrationTestTimeBoundedRequestsWithRegionReplicas kills 
the servers, but expects the requests with backup RPCs (going to replicas) to 
finish under some limited time (5sec, etc). Meta for this test is a single 
point of failure, and will cause the test to fail (unless HBASE-11574 is used 
with the test).

The serverKilling monkey is still useful I think which does not to other 
actions (like snapshot, etc). Maybe we can rename serverKilling monkey to 
serverKillingWithoutMeta and change the serverKilling monkey to kill meta. 

 Make ITBLL less of a wuss
 -

 Key: HBASE-12955
 URL: https://issues.apache.org/jira/browse/HBASE-12955
 Project: HBase
  Issue Type: Task
Reporter: stack
Assignee: stack

 ITBLL avoids rolling restart and kill of the server hosting meta by default.
 {code}
  Action[] actions1 = new Action[] {
 -new RestartRandomRsExceptMetaAction(6),
 +new RestartRandomRsAction(6),
  new RestartActiveMasterAction(5000),
 -new RollingBatchRestartRsExceptMetaAction(5000, 1.0f, 2), //only 
 allow 2 servers to be dead
 +new RollingBatchRestartRsAction(5000, 1.0f, 2), //only allow 2 
 servers to be dead
  new ForceBalancerAction()
 {code}
 Enable killing of meta.
 Running tests over the w/e against 1.0, all seems to work w/ this enabled 
 (splits were disabled).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301975#comment-14301975
]

Andrew Purtell commented on HBASE-12954:

This is similar of course to issues operators face on EC2 clouds, where the
reverse resolved internal DNS names are of no use unless all clients are also
using the internal resolvers.

So like Stack suggested, we need to disconnect the hostnames HBase uses
internally from those posted to ZK for external consumption. One option could
be to do it like HDFS rack mapping: a configuration property specifies a script
that the master will execute to map IP addresses to internal and external
names. It takes as input the IP address and a flag that specifies internal or
external. The results from executing the script with internal would be
handed to regionservers as their identity, the results from executing with
external would be advertised in ZooKeeper.

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (HBASE-12954) Ability impaired using HBase on multihomed hosts

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301975#comment-14301975
]

Andrew Purtell edited comment on HBASE-12954 at 2/2/15 9:36 PM:

This is similar of course to issues operators face on EC2 clouds, where the
reverse resolved internal DNS names are of no use unless all clients are also
using the internal resolvers.

Edit: Or invoke the script once and have it hand back all necessary
information, structured as YAML or JSON or similar.

was (Author: apurtell):
This is similar of course to issues operators face on EC2 clouds, where the
reverse resolved internal DNS names are of no use unless all clients are also
using the internal resolvers.

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301866#comment-14301866
]

Andrew Purtell commented on HBASE-12954:

[~tedyu], your test needs to simulate a hostname resolving to foo.bar.com at
the regionserver and baz.bar.com at the master for the same IP address. This
sometimes happens. It is necessary for the master to tell the regionserver its
identity lest we resurrect data loss issues from the past due to multiple
assignment. You'll need to find a solution where the master remains in charge
of defining regionserver identities.

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

2015-02-02 Thread Ted Yu (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301996#comment-14301996
]

Ted Yu commented on HBASE-12954:

Currently HRegionServer has one ServerName field.
In the above design, looks like it would maintain two ServerName fields.

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12952) Seek with prefixtree may hang


 [ 
https://issues.apache.org/jira/browse/HBASE-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-12952:
---
Assignee: sinfox

 Seek with prefixtree may hang
 -

 Key: HBASE-12952
 URL: https://issues.apache.org/jira/browse/HBASE-12952
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 1.0.0, 0.98.7, 0.98.8, 0.98.6.1, 0.98.9, 0.98.10
Reporter: sinfox
Assignee: sinfox
 Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.11

 Attachments: hbase_0.98.6.1.patch


 I have upgraded my hbase cluster from hbase-0.96 to hbase-0.98.6.1,then i 
 found some compaction hang on many regionserver, and the cpu costed100%.
 It looks like there is an infinite loop somewhere. 
 From the log, i found StoreFileScanner.java : reseekAtOrAfter(HFileScanner s, 
 KeyValue k) enterd an infinite loop.
 Read source code, I found en error on PrefixTreeArrayReversibleScanner.java : 
 previousRowInternal()
 eg:  
   A:fan:12, numCell:1
   A : 1  - B
   A : 2  - C
   
   C: 3  - D
   C: 4  - E
   
 A: fan:12, numCell:1
 B: fan,numCell:1
 C: fan:34,numCell: 0
 D: fan,numCell:1
 E: fan,numCell:1
 when currentNode is D, its previous node is B , but this function will return 
 A.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12948) Increment#addColumn on the same column multi times produce wrong result


[ 
https://issues.apache.org/jira/browse/HBASE-12948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302059#comment-14302059
 ] 

Andrew Purtell commented on HBASE-12948:


A new method plus deprecation of the old will be fine, but we can't at this 
point change current 0.98 behavior of the old (and presumably to be deprecated) 
method. 

 Increment#addColumn on the same column multi times produce wrong result 
 

 Key: HBASE-12948
 URL: https://issues.apache.org/jira/browse/HBASE-12948
 Project: HBase
  Issue Type: Bug
  Components: Client, regionserver
Reporter: hongyu bi
Priority: Critical
 Attachments: 12948-v2.patch, 12948-v3.patch, 
 HBASE-12948-0.99.2-v1.patch, HBASE-12948-v0.patch, HBASE-12948.patch


 Case:
 Initially get('row1'):
 rowkey=row1 value=1
 run:
 Increment increment = new Increment(Bytes.toBytes(row1));
 for (int i = 0; i  N; i++) {
 increment.addColumn(Bytes.toBytes(cf), Bytes.toBytes(c), 1)
 }
 hobi.increment(increment);
 get('row1'):
 if N=1 then result is 2 else if N1 the result will always be 1
 Cause:
 https://issues.apache.org/jira/browse/HBASE-7114 let increment extent 
 mutation which change familyMap from NavigableMap to List, so from client 
 side, we can buffer many edits on the same column；
 However, HRegion#increment use idx to iterate the get's results, here 
 results.sizefamily.value().size if N1，so the latter edits on the same 
 column won't match the condition {idx  results.size()  
 CellUtil.matchingQualifier(results.get(idx), kv) }, meantime the edits share 
 the same mvccVersion ,so this case happen.
 Fix:
 according to the put/delete#add on the same column behaviour ,
 fix from server side: process last edit wins on the same column inside 
 HRegion#increment to maintenance  HBASE-7114's extension and keep the same 
 result from 0.94.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302519#comment-14302519
]

Enis Soztutar commented on HBASE-12954:
---

bq. So like Stack suggested, we need to disconnect the hostnames HBase uses
internally from those posted to ZK for external consumption
Maybe my understanding of this is not correct. I thought that we want to
standardize on the hostnames used both internally and externally, but we do not
want to do a reverse DNS resolution necessarily. In this case both the master
address in zookeeper, and the region server addresses in meta table will be
coming from configured (and hardcoded) hostnames. We can still have the master
verify the hostname provided from the regionserver, and use it only if the
forward resolution works. Otherwise it rejects the RS. The RS will never use
hostnames other than configured.
The traffic from master to RS or RS to RS can be separated out (if wanted)
using custom hosts file or DNS setup.

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302538#comment-14302538
]

stack commented on HBASE-12954:
---

bq. I thought that we want to standardize on the hostnames used both internally
and externally, but we do not want to do a reverse DNS resolution necessarily.
In this case both the master address in zookeeper, and the region server
addresses in meta table will be coming from configured (and hardcoded)
hostnames. We can still have the master verify the hostname provided from the
regionserver, and use it only if the forward resolution works. Otherwise it
rejects the RS. The RS will never use hostnames other than configured.

You are not describing how it currently works -- master tells the RS what to
use so no need of reverse lookup -- nor are you describing what is in this
patch (RS is rejected if it does not agree w/ what master has). Are you
suggesting how it might work [~enis]?

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-10942) support parallel request cancellation for multi-get

2015-02-02 Thread Devaraj Das (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Devaraj Das updated HBASE-10942:

Attachment: 10942-branch-1.txt

Thanks for the reviews, [~nkeywal] and [~ndimiduk]. Great to see you, 
[~nkeywal]! Attaching a patch for branch-1.

 support parallel request cancellation for multi-get
 ---

 Key: HBASE-10942
 URL: https://issues.apache.org/jira/browse/HBASE-10942
 Project: HBase
  Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Nicolas Liochon
 Fix For: hbase-10070

 Attachments: 10942-1.1.txt, 10942-branch-1.txt, 10942-for-98.zip, 
 10942.patch, HBASE-10942.01.patch, HBASE-10942.02.patch, HBASE-10942.patch






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12035) Client does an RPC to master everytime a region is relocated


[ 
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302588#comment-14302588
 ] 

Andrey Stepachev commented on HBASE-12035:
--

[~stack] Thank you for looking at this patch. 
As for CellComparator I think it should work, lexicographically table row will 
be before region rows. I checked, and hope all scans set catalog family 
explicitly, so they shouldn't see table row if they don't expect them.

As for branch-1 it can be ever simplier, because there is no protobuf  and 
table descriptors still the same. 
Migration can be made in TableStateManager, it can read states from zk and 
update meta accordingly.
If we don't want to support states in zk (that could break some apps, that are 
rely state in zk instead),
we can make migration. If we want to keep things compatible, that would be a 
bit more work to support 
zkwatcher and state duplication to zk (may be with configuration property like 
'enable.zk.state.compat')

 Client does an RPC to master everytime a region is relocated
 

 Key: HBASE-12035
 URL: https://issues.apache.org/jira/browse/HBASE-12035
 Project: HBase
  Issue Type: Improvement
  Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
 Fix For: 2.0.0

 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch


 HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of 
 zookeeper. isTableDisabled() which is used in 
 HConnectionImplementation.relocateRegion() now became a master RPC call 
 rather than a zookeeper client call. Since we do relocateRegion() calls 
 everytime we want to relocate a region (region moved, RS down, etc) this 
 implies that when the master is down, the some of the clients for uncached 
 regions will be affected. 
 See HBASE-7767 and HBASE-11974 for some more background. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302622#comment-14302622
]

Enis Soztutar commented on HBASE-12954:
---

bq. You are not describing how it currently works – master tells the RS what to
use so no need of reverse lookup
The RS connects to master with it's ip. Master does a reverse lookup (no?), and
tells that to the region server its own hostname and RS uses it from then on.
At least that is what I understand from the current code.
What I am proposing is a slight alteration (which is similar to what the patch
has since I was involved in the initial discussions for the patch) that:
- we configure a hostname for the regionserver
- RS sends the configured hostname over the region server startup rpc.
- Master does not do a reverse DNS resolution, but instead uses the hostname
coming from the RPC parameters.
- Master does a forward resolution of the hostname to verify that it can talk
to the region server.
- The hostname (ServerName) is passed back to the RS, which uses it from then
on.
Again, correct me if I am wrong. I'll re-check the code.

Ability impaired using HBase on multihomed hosts

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12035) Client does an RPC to master everytime a region is relocated


 [ 
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Stepachev updated HBASE-12035:
-
Attachment: HBASE-12035.patch

+ fixing wrong delete from meta
+ fixing broken test 
+ fixing npe in EnableTableHandler
+ fixing npe in RpcServer
+ fixing long lines

 Client does an RPC to master everytime a region is relocated
 

 Key: HBASE-12035
 URL: https://issues.apache.org/jira/browse/HBASE-12035
 Project: HBase
  Issue Type: Improvement
  Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
 Fix For: 2.0.0

 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch


 HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of 
 zookeeper. isTableDisabled() which is used in 
 HConnectionImplementation.relocateRegion() now became a master RPC call 
 rather than a zookeeper client call. Since we do relocateRegion() calls 
 everytime we want to relocate a region (region moved, RS down, etc) this 
 implies that when the master is down, the some of the clients for uncached 
 regions will be affected. 
 See HBASE-7767 and HBASE-11974 for some more background. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12035) Client does an RPC to master everytime a region is relocated


 [ 
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Stepachev updated HBASE-12035:
-
Status: Patch Available  (was: Open)

 Client does an RPC to master everytime a region is relocated
 

 Key: HBASE-12035
 URL: https://issues.apache.org/jira/browse/HBASE-12035
 Project: HBase
  Issue Type: Improvement
  Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
 Fix For: 2.0.0

 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch


 HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of 
 zookeeper. isTableDisabled() which is used in 
 HConnectionImplementation.relocateRegion() now became a master RPC call 
 rather than a zookeeper client call. Since we do relocateRegion() calls 
 everytime we want to relocate a region (region moved, RS down, etc) this 
 implies that when the master is down, the some of the clients for uncached 
 regions will be affected. 
 See HBASE-7767 and HBASE-11974 for some more background. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-12956) Binding to 0.0.0.0 is broken after HBASE-10569

2015-02-02 Thread Esteban Gutierrez (JIRA)

Esteban Gutierrez created HBASE-12956:
-

 Summary: Binding to 0.0.0.0 is broken after HBASE-10569
 Key: HBASE-12956
 URL: https://issues.apache.org/jira/browse/HBASE-12956
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Esteban Gutierrez


After the Region Server and Master code was merged, we lost the functionality 
to bind to 0.0.0.0 via hbase.regionserver.ipc.address and znodes now get 
created with the wildcard address which means that RSs and the master. Thanks 
to [~dimaspivak] for reporting the issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12867) Shell does not support custom replication endpoint specification


 [ 
https://issues.apache.org/jira/browse/HBASE-12867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar updated HBASE-12867:
--
Attachment: HBASE-12867-v3.patch

Reattach again. 

 Shell does not support custom replication endpoint specification
 

 Key: HBASE-12867
 URL: https://issues.apache.org/jira/browse/HBASE-12867
 Project: HBase
  Issue Type: Bug
Reporter: Andrew Purtell
Assignee: Kevin Risden
  Labels: beginner, beginners
 Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.11

 Attachments: HBASE-12867-v1.patch, HBASE-12867-v2.patch, 
 HBASE-12867-v3.patch, HBASE-12867-v3.patch, HBASE-12867-v3.patch, 
 HBASE-12867.patch


 On HBASE-12254 and also at 
 https://github.com/risdenk/hbase-custom-replication-endpoint-example 
 [~risdenk] made the following observations and suggestions regarding custom 
 replication endpoints that I think are a reasonable blueprint for improvement:
 {quote}
 I was trying out the pluggable replication endpoint feature and found the 
 following:
 - you must use the ReplicationAdmin to add the new ReplicationEndpoint
 - hbase shell add_peer command doesn't support specifying a custom class
 - hbase shell add_peer relies on the newly deprecated ReplicationAdmin 
 addPeer methods
 - ReplicationAdmin addPeer tableCfs is now a MapTableName, ? extends 
 CollectionString instead of a string
 {quote}
 We should fix the add_peer command in the shell at least.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12035) Client does an RPC to master everytime a region is relocated


 [ 
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Stepachev updated HBASE-12035:
-
Status: Open  (was: Patch Available)

 Client does an RPC to master everytime a region is relocated
 

 Key: HBASE-12035
 URL: https://issues.apache.org/jira/browse/HBASE-12035
 Project: HBase
  Issue Type: Improvement
  Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
 Fix For: 2.0.0

 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch


 HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of 
 zookeeper. isTableDisabled() which is used in 
 HConnectionImplementation.relocateRegion() now became a master RPC call 
 rather than a zookeeper client call. Since we do relocateRegion() calls 
 everytime we want to relocate a region (region moved, RS down, etc) this 
 implies that when the master is down, the some of the clients for uncached 
 regions will be affected. 
 See HBASE-7767 and HBASE-11974 for some more background. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-10942) support parallel request cancellation for multi-get

2015-02-02 Thread Nick Dimiduk (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302612#comment-14302612
 ] 

Nick Dimiduk commented on HBASE-10942:
--

Patch looks good to me. +1 ... though which branch is this intended for? I 
thought 10070 branch was dead. The file name contains 1.1, so does that mean 
branch-1? Would be good to get branch-specific HadoopQA output for each target 
branch for this patch.

 support parallel request cancellation for multi-get
 ---

 Key: HBASE-10942
 URL: https://issues.apache.org/jira/browse/HBASE-10942
 Project: HBase
  Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Nicolas Liochon
 Fix For: hbase-10070

 Attachments: 10942-1.1.txt, 10942-for-98.zip, 10942.patch, 
 HBASE-10942.01.patch, HBASE-10942.02.patch, HBASE-10942.patch






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12035) Client does an RPC to master everytime a region is relocated

[
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302607#comment-14302607
]

stack commented on HBASE-12035:
---

bq. Migration can be made in TableStateManager, it can read states from zk and
update meta accordingly.

This sounds great.

bq. If we don't want to support states in zk (that could break some apps, that
are rely state in zk instead), we can make migration.

I would say that is you were reading from zk directly, its ok that you are
broken when you go to branch-1. We can write up a release note when it goes in
and call it out loudly.

Client does an RPC to master everytime a region is relocated

Key: HBASE-12035
URL: https://issues.apache.org/jira/browse/HBASE-12035
Project: HBase
Issue Type: Improvement
Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
Fix For: 2.0.0

Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch,
HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch,
HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch

HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of
zookeeper. isTableDisabled() which is used in
HConnectionImplementation.relocateRegion() now became a master RPC call
rather than a zookeeper client call. Since we do relocateRegion() calls
everytime we want to relocate a region (region moved, RS down, etc) this
implies that when the master is down, the some of the clients for uncached
regions will be affected.
See HBASE-7767 and HBASE-11974 for some more background.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (HBASE-10942) support parallel request cancellation for multi-get

2015-02-02 Thread Devaraj Das (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302637#comment-14302637
 ] 

Devaraj Das edited comment on HBASE-10942 at 2/3/15 1:38 AM:
-

Thanks for the reviews, [~nkeywal] and [~ndimiduk]. Great to see you, 
[~nkeywal]! Attaching a patch for branch-1 (the previous one was for the 
master).


was (Author: devaraj):
Thanks for the reviews, [~nkeywal] and [~ndimiduk]. Great to see you, 
[~nkeywal]! Attaching a patch for branch-1.

 support parallel request cancellation for multi-get
 ---

 Key: HBASE-10942
 URL: https://issues.apache.org/jira/browse/HBASE-10942
 Project: HBase
  Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Nicolas Liochon
 Fix For: hbase-10070

 Attachments: 10942-1.1.txt, 10942-branch-1.txt, 10942-for-98.zip, 
 10942.patch, HBASE-10942.01.patch, HBASE-10942.02.patch, HBASE-10942.patch






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12035) Client does an RPC to master everytime a region is relocated


[ 
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302638#comment-14302638
 ] 

Andrey Stepachev commented on HBASE-12035:
--

[~stack] great. let's roll that into branch2 and then I'll make backport to 
branch1.
(btw, currently there is already code for migration, just need to teach it to 
go to zk)

 Client does an RPC to master everytime a region is relocated
 

 Key: HBASE-12035
 URL: https://issues.apache.org/jira/browse/HBASE-12035
 Project: HBase
  Issue Type: Improvement
  Components: Client, master
Affects Versions: 2.0.0
Reporter: Enis Soztutar
Assignee: Andrey Stepachev
Priority: Critical
 Fix For: 2.0.0

 Attachments: HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch, 
 HBASE-12035.patch, HBASE-12035.patch, HBASE-12035.patch


 HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of 
 zookeeper. isTableDisabled() which is used in 
 HConnectionImplementation.relocateRegion() now became a master RPC call 
 rather than a zookeeper client call. Since we do relocateRegion() calls 
 everytime we want to relocate a region (region moved, RS down, etc) this 
 implies that when the master is down, the some of the clients for uncached 
 regions will be affected. 
 See HBASE-7767 and HBASE-11974 for some more background. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-12953) RegionServer is not functionally working with AysncRpcClient in secure mode

2015-02-02 Thread Ashish Singhi (JIRA)

Ashish Singhi created HBASE-12953:
-

 Summary: RegionServer is not functionally working with 
AysncRpcClient in secure mode
 Key: HBASE-12953
 URL: https://issues.apache.org/jira/browse/HBASE-12953
 Project: HBase
  Issue Type: Bug
  Components: security
Affects Versions: 2.0.0, 1.1.0
Reporter: Ashish Singhi
Priority: Critical


HBase version 2.0.0
Default value for {{hbase.rpc.client.impl}} is set to AsyncRpcClient.
When trying to install HBase with Kerberos, RegionServer is not working 
functionally.
The following log is logged in its log file
{noformat}
2015-02-02 14:59:05,407 WARN  [AsyncRpcChannel-pool1-t1] 
channel.DefaultChannelPipeline: An exceptionCaught() event was fired, and it 
reached at the tail of the pipeline. It usually means the last handler in the 
pipeline did not handle the exception.
io.netty.channel.ChannelPipelineException: 
org.apache.hadoop.hbase.security.SaslClientHandler.handlerAdded() has thrown an 
exception; removed.
at 
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:499)
at 
io.netty.channel.DefaultChannelPipeline.callHandlerAdded(DefaultChannelPipeline.java:481)
at 
io.netty.channel.DefaultChannelPipeline.addFirst0(DefaultChannelPipeline.java:114)
at 
io.netty.channel.DefaultChannelPipeline.addFirst(DefaultChannelPipeline.java:97)
at 
io.netty.channel.DefaultChannelPipeline.addFirst(DefaultChannelPipeline.java:235)
at 
io.netty.channel.DefaultChannelPipeline.addFirst(DefaultChannelPipeline.java:214)
at 
org.apache.hadoop.hbase.ipc.AsyncRpcChannel$2.operationComplete(AsyncRpcChannel.java:194)
at 
org.apache.hadoop.hbase.ipc.AsyncRpcChannel$2.operationComplete(AsyncRpcChannel.java:157)
at 
io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:680)
at 
io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:603)
at 
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:563)
at 
io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:406)
at 
io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:82)
at 
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:253)
at 
io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:288)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:528)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by 
GSSException: No valid credentials provided (Mechanism level: Failed to find 
any Kerberos tgt)]
at 
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
at 
org.apache.hadoop.hbase.security.SaslClientHandler.handlerAdded(SaslClientHandler.java:154)
at 
io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:486)
... 20 more
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed 
to find any Kerberos tgt)
at 
sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147)
at 
sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:121)
at 
sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at 
sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:223)
at 
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at 
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at 
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
{noformat}

When set hbase.rpc.client.impl to RpcClientImpl, there seems to be no issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12948) Increment#addColumn on the same column multi times produce wrong result


[ 
https://issues.apache.org/jira/browse/HBASE-12948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301072#comment-14301072
 ] 

Hadoop QA commented on HBASE-12948:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12695886/12948-v3.patch
  against master branch at commit 86b8b8da0082bea9e8b9c43df917acd67a680cd1.
  ATTACHMENT ID: 12695886

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:red}-1 checkstyle{color}.  The applied patch generated 
1938 checkstyle errors (more than the master's current 1936 errors).

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//artifact/patchprocess/checkstyle-aggregate.html

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/12667//console

This message is automatically generated.

 Increment#addColumn on the same column multi times produce wrong result 
 

 Key: HBASE-12948
 URL: https://issues.apache.org/jira/browse/HBASE-12948
 Project: HBase
  Issue Type: Bug
  Components: Client, regionserver
Reporter: hongyu bi
Priority: Critical
 Attachments: 12948-v2.patch, 12948-v3.patch, 
 HBASE-12948-0.99.2-v1.patch, HBASE-12948-v0.patch, HBASE-12948.patch


 Case:
 Initially get('row1'):
 rowkey=row1 value=1
 run:
 Increment increment = new Increment(Bytes.toBytes(row1));
 for (int i = 0; i  N; i++) {
 increment.addColumn(Bytes.toBytes(cf), Bytes.toBytes(c), 1)
 }
 hobi.increment(increment);
 get('row1'):
 if N=1 then result is 2 else if N1 the result will always be 1
 Cause:
 https://issues.apache.org/jira/browse/HBASE-7114 let increment extent 
 mutation which change familyMap from NavigableMap to List, so from client 
 side, we can buffer many edits on the same column；
 However, HRegion#increment use idx to iterate the get's results, here 
 results.sizefamily.value().size if N1，so the latter edits on the same 
 column won't match the condition {idx  results.size()  
 CellUtil.matchingQualifier(results.get(idx), kv) }, meantime the edits share 
 the same mvccVersion

[jira] [Commented] (HBASE-8329) Limit compaction speed

2015-02-02 Thread zhangduo (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302790#comment-14302790
 ] 

zhangduo commented on HBASE-8329:
-

[~stack] There are some conflicts when cherry picking to branch-1. Let me 
resolve them. Patch will be ready soon.
And I also have a patch for 0.98 that is currently used in our cluster. Is it 
worth to also port this it to 0.98? [~apurtell]

Thanks~

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-10.patch, HBASE-8329-11.patch, 
 HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, HBASE-8329-3-trunk.patch, 
 HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, HBASE-8329-6-trunk.patch, 
 HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, HBASE-8329-9-trunk.patch, 
 HBASE-8329-trunk.patch, HBASE-8329_13.patch, HBASE-8329_14.patch, 
 HBASE-8329_15.patch, HBASE-8329_16.patch, HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-8329) Limit compaction speed

2015-02-02 Thread zhangduo (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

zhangduo updated HBASE-8329:

Attachment: HBASE-8329-branch-1.patch

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-10.patch, HBASE-8329-11.patch, 
 HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, HBASE-8329-3-trunk.patch, 
 HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, HBASE-8329-6-trunk.patch, 
 HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, HBASE-8329-9-trunk.patch, 
 HBASE-8329-branch-1.patch, HBASE-8329-trunk.patch, HBASE-8329_13.patch, 
 HBASE-8329_14.patch, HBASE-8329_15.patch, HBASE-8329_16.patch, 
 HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-8329) Limit compaction speed


[ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302798#comment-14302798
 ] 

stack commented on HBASE-8329:
--

Will wait on the branch-1 patch before applying so they go in together.

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-10.patch, HBASE-8329-11.patch, 
 HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, HBASE-8329-3-trunk.patch, 
 HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, HBASE-8329-6-trunk.patch, 
 HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, HBASE-8329-9-trunk.patch, 
 HBASE-8329-branch-1.patch, HBASE-8329-trunk.patch, HBASE-8329_13.patch, 
 HBASE-8329_14.patch, HBASE-8329_15.patch, HBASE-8329_16.patch, 
 HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-8329) Limit compaction speed


[ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302797#comment-14302797
 ] 

stack commented on HBASE-8329:
--

[~Apache9] Would be coolio if you could report on how it is doing in your 
cluster, if it helps, etc.

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-10.patch, HBASE-8329-11.patch, 
 HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, HBASE-8329-3-trunk.patch, 
 HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, HBASE-8329-6-trunk.patch, 
 HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, HBASE-8329-9-trunk.patch, 
 HBASE-8329-branch-1.patch, HBASE-8329-trunk.patch, HBASE-8329_13.patch, 
 HBASE-8329_14.patch, HBASE-8329_15.patch, HBASE-8329_16.patch, 
 HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12108) HBaseConfiguration

2015-02-02 Thread Aniket Bhatnagar (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aniket Bhatnagar updated HBASE-12108:
-
   Labels: class_loader configuration patch  (was: )
Affects Version/s: 0.98.6
 Release Note: HBASE-12108 - This patch fixes hbase configuration not 
found issues when HBase jars are loaded in a child class loader whose parent 
has already loaded hadoop classes. Setting appropriate classloader in 
Configuration should fix this issue.
   Status: Patch Available  (was: Open)

This fixes https://issues.apache.org/jira/browse/HBASE-12108

 HBaseConfiguration
 --

 Key: HBASE-12108
 URL: https://issues.apache.org/jira/browse/HBASE-12108
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.6
Reporter: Aniket Bhatnagar
Priority: Minor
  Labels: patch, configuration, class_loader

 IN the setup wherein HBase jars are loaded in child classloader whose parent 
 had loaded hadoop-common jar, HBaseConfiguration.create() throws 
 hbase-default.xml file seems to be for and old version of HBase (null)...  
 exception. ClassLoader should be set in Hadoop conf object before calling 
 addHbaseResources method



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12035) Client does an RPC to master everytime a region is relocated

[
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302680#comment-14302680
]

Hadoop QA commented on HBASE-12035:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12696058/HBASE-12035.patch
against master branch at commit fef78acf6534f6736c10d2054cf8cb479edd3291.
ATTACHMENT ID: 12696058

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 tests included{color}. The patch appears to include 42 new
or modified tests.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestMetaWithReplicas

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//artifact/patchprocess/checkstyle-aggregate.html

Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12672//console

This message is automatically generated.

Client does an RPC to master everytime a region is relocated

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-8329) Limit compaction speed

2015-02-02 Thread zhangduo (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

zhangduo updated HBASE-8329:

Attachment: HBASE-8329_17.patch

Address issues on rb

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-10.patch, HBASE-8329-11.patch, 
 HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, HBASE-8329-3-trunk.patch, 
 HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, HBASE-8329-6-trunk.patch, 
 HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, HBASE-8329-9-trunk.patch, 
 HBASE-8329-trunk.patch, HBASE-8329_13.patch, HBASE-8329_14.patch, 
 HBASE-8329_15.patch, HBASE-8329_16.patch, HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-7332) [webui] HMaster webui should display the number of regions a table has.


[ 
https://issues.apache.org/jira/browse/HBASE-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302835#comment-14302835
 ] 

stack commented on HBASE-7332:
--

Patch looks good. When does stuff get cleared from here?

79private final MapTableName, MapString, RegionState 
regionStatesTableIndex =
80new HashMapTableName, MapString, RegionState();


 [webui] HMaster webui should display the number of regions a table has.
 ---

 Key: HBASE-7332
 URL: https://issues.apache.org/jira/browse/HBASE-7332
 Project: HBase
  Issue Type: Bug
  Components: UI
Affects Versions: 2.0.0, 1.1.0
Reporter: Jonathan Hsieh
Assignee: Andrey Stepachev
Priority: Minor
  Labels: beginner
 Attachments: HBASE-7332.patch, Screen Shot 2014-07-28 at 4.10.01 
 PM.png


 Pre-0.96/trunk hbase displayed the number of regions per table in the table 
 listing.  Would be good to have this back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-8329) Limit compaction speed