date:20111216


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

nkeywal updated HBASE-5051:
---

Attachment: 5051.patch

 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5022) Optimize HBaseConfiguration#create

2011-12-16 Thread ramkrishna.s.vasudevan (Updated) (JIRA)


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

nkeywal updated HBASE-5022:
---

Resolution: Fixed
Status: Resolved  (was: Patch Available)

 Optimize HBaseConfiguration#create
 --

 Key: HBASE-5022
 URL: https://issues.apache.org/jira/browse/HBASE-5022
 Project: HBase
  Issue Type: Improvement
  Components: performance
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5022.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5009) Failure of creating split dir if it already exists prevents splits from happening further


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

ramkrishna.s.vasudevan updated HBASE-5009:
--

Attachment: HBASE-5009_Branch90.patch

Patch for 0.90

 Failure of creating split dir if it already exists prevents splits from 
 happening further
 -

 Key: HBASE-5009
 URL: https://issues.apache.org/jira/browse/HBASE-5009
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-5009_Branch90.patch


 The scenario is
 - The split of a region takes a long time
 - The deletion of the splitDir fails due to HDFS problems.
 - Subsequent splits also fail after that.
 {code}
 private static void createSplitDir(final FileSystem fs, final Path splitdir)
   throws IOException {
 if (fs.exists(splitdir)) throw new IOException(Splitdir already exits?  
 + splitdir);
 if (!fs.mkdirs(splitdir)) throw new IOException(Failed create of  + 
 splitdir);
   }
 {code}
 Correct me if am wrong? If it is an issue can we change the behaviour of 
 throwing exception?
 Pls suggest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5009) Failure of creating split dir if it already exists prevents splits from happening further

2011-12-16 Thread ramkrishna.s.vasudevan (Updated) (JIRA)


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

ramkrishna.s.vasudevan updated HBASE-5009:
--

Attachment: HBASE-5009.patch

Patch for trunk

 Failure of creating split dir if it already exists prevents splits from 
 happening further
 -

 Key: HBASE-5009
 URL: https://issues.apache.org/jira/browse/HBASE-5009
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-5009.patch, HBASE-5009_Branch90.patch


 The scenario is
 - The split of a region takes a long time
 - The deletion of the splitDir fails due to HDFS problems.
 - Subsequent splits also fail after that.
 {code}
 private static void createSplitDir(final FileSystem fs, final Path splitdir)
   throws IOException {
 if (fs.exists(splitdir)) throw new IOException(Splitdir already exits?  
 + splitdir);
 if (!fs.mkdirs(splitdir)) throw new IOException(Failed create of  + 
 splitdir);
   }
 {code}
 Correct me if am wrong? If it is an issue can we change the behaviour of 
 throwing exception?
 Pls suggest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5052) The path where a dynamically loaded coprocessor jar is copied on the local file system depends on the region name (and implicitly, the start key)

2011-12-16 Thread ramkrishna.s.vasudevan (Commented) (JIRA)

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

Hadoop QA commented on HBASE-5052:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507668/HBASE-5052.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

-1 tests included. 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.

-1 javadoc. The javadoc tool appears to have generated -152 warning
messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 76 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.coprocessor.TestMasterObserver
org.apache.hadoop.hbase.regionserver.wal.TestLogRolling
org.apache.hadoop.hbase.client.TestInstantSchemaChange
org.apache.hadoop.hbase.master.TestDistributedLogSplitting

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/519//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/519//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/519//console

This message is automatically generated.

The path where a dynamically loaded coprocessor jar is copied on the local
file system depends on the region name (and implicitly, the start key)
-

Key: HBASE-5052
URL: https://issues.apache.org/jira/browse/HBASE-5052
Project: HBase
Issue Type: Bug
Components: coprocessors
Affects Versions: 0.92.0
Reporter: Andrei Dragomir
Attachments: HBASE-5052.patch

When loading a coprocessor from hdfs, the jar file gets copied to a path on
the local filesystem, which depends on the region name, and the region start
key. The name is cleaned, but not enough, so when you have filesystem
unfriendly characters (/?:, etc), the coprocessor is not loaded, and an error
is thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5009) Failure of creating split dir if it already exists prevents splits from happening further


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

ramkrishna.s.vasudevan commented on HBASE-5009:
---

The threadPool.awaitTermination() will ensure that the background thread pool 
is completed.  
Also FSUtils.create() was doing an exists check and then createNewFile().  It 
was followed by create().  Changed it to fs.create(p, false).  If the path had 
existed it will throw exception.
Pls review

 Failure of creating split dir if it already exists prevents splits from 
 happening further
 -

 Key: HBASE-5009
 URL: https://issues.apache.org/jira/browse/HBASE-5009
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-5009.patch, HBASE-5009_Branch90.patch


 The scenario is
 - The split of a region takes a long time
 - The deletion of the splitDir fails due to HDFS problems.
 - Subsequent splits also fail after that.
 {code}
 private static void createSplitDir(final FileSystem fs, final Path splitdir)
   throws IOException {
 if (fs.exists(splitdir)) throw new IOException(Splitdir already exits?  
 + splitdir);
 if (!fs.mkdirs(splitdir)) throw new IOException(Failed create of  + 
 splitdir);
   }
 {code}
 Correct me if am wrong? If it is an issue can we change the behaviour of 
 throwing exception?
 Pls suggest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5053) HCM Tests leaks connections

2011-12-16 Thread nkeywal (Created) (JIRA)

HCM Tests leaks connections
---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor


There are simple leaks and one more complex.

The complex one comes from the fact fact 
HConnectionManager.HConnectionImplementation keeps a *reference* to the 
configuration used for the creation. So if this configuration is updated later, 
the HConnectionKey created initially will differ from the current one. As a 
consequence, the close() will not find the connection anymore in the list, and 
the connection won't be deleted.

I added a warning when a close does not find the connection in the list; but I 
wonder if we should not copy the HConnectionKey instead of keeping a reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Attachment: 5053.patch

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Status: Patch Available  (was: Open)

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call


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

nkeywal updated HBASE-5051:
---

Status: Patch Available  (was: Open)

 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.

2011-12-16 Thread Jonathan Hsieh (Assigned) (JIRA)


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

Jonathan Hsieh reassigned HBASE-4934:
-

Assignee: Jonathan Hsieh

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor

 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-16 Thread Zhihong Yu (Issue Comment Edited) (JIRA)


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

Zhihong Yu commented on HBASE-4938:
---

Hadoop Qa uses attachment Id to not rerun same attachment. 
That's why a new file has to be attached. 

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint


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

Zhihong Yu edited comment on HBASE-4938 at 12/16/11 2:08 PM:
-

Hadoop Qa checks attachment Id to not rerun same attachment. 
That's why a new file has to be attached. 

  was (Author: zhi...@ebaysf.com):
Hadoop Qa uses attachment Id to not rerun same attachment. 
That's why a new file has to be attached. 
  
 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.


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

Jonathan Hsieh updated HBASE-4934:
--

Attachment: hbase-4934.patch

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.


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

Jonathan Hsieh updated HBASE-4934:
--

Affects Version/s: 0.92.0
   Status: Patch Available  (was: Open)

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.


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

Jonathan Hsieh updated HBASE-4934:
--

Attachment: hregion.png
hmaster.png

Attached screen shots.  Notice extra fields at end of the first attributes 
block, and also human readable data in region server list.

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch, hmaster.png, hregion.png


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.

2011-12-16 Thread Jonathan Hsieh (Commented) (JIRA)


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

Jonathan Hsieh commented on HBASE-4934:
---

I find this useful for quickly determining which regionservers have been 
restarted/resurrected.

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch, hmaster.png, hregion.png


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

Hadoop QA commented on HBASE-5053:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507688/5053.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified tests.

-1 javadoc. The javadoc tool appears to have generated -152 warning
messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 76 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestInstantSchemaChange

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/520//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/520//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/520//console

This message is automatically generated.

HCM Tests leaks connections
---

Key: HBASE-5053
URL: https://issues.apache.org/jira/browse/HBASE-5053
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
Attachments: 5053.patch

There are simple leaks and one more complex.
The complex one comes from the fact fact
HConnectionManager.HConnectionImplementation keeps a *reference* to the
configuration used for the creation. So if this configuration is updated
later, the HConnectionKey created initially will differ from the current one.
As a consequence, the close() will not find the connection anymore in the
list, and the connection won't be deleted.
I added a warning when a close does not find the connection in the list; but
I wonder if we should not copy the HConnectionKey instead of keeping a
reference.

[jira] [Commented] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.

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

Hadoop QA commented on HBASE-4934:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507693/hregion.png
against trunk revision .

+1 @author. The patch does not contain any @author tags.

-1 patch. The patch command could not apply the patch.

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

This message is automatically generated.

Display Master server and Regionserver start time on respective info servers.
-

Key: HBASE-4934
URL: https://issues.apache.org/jira/browse/HBASE-4934
Project: HBase
Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
Attachments: hbase-4934.patch, hmaster.png, hregion.png

With operations like rolling restart or master failovers, it is difficult to
tell if a server is the old instance or the new restarted instance.
Adding a start date stamp on the info web pages would be helpful for
determining this.

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections


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

nkeywal commented on HBASE-5053:


org.apache.hadoop.hbase.client.TestInstantSchemaChange = Too many open files

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call

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

Hadoop QA commented on HBASE-5051:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507670/5051.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 36 new or modified tests.

-1 javadoc. The javadoc tool appears to have generated -152 warning
messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 76 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:

org.apache.hadoop.hbase.master.TestMasterRestartAfterDisablingTable
org.apache.hadoop.hbase.replication.TestReplication
org.apache.hadoop.hbase.client.TestInstantSchemaChange

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/521//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/521//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/521//console

This message is automatically generated.

HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each
call
--

Key: HBASE-5051
URL: https://issues.apache.org/jira/browse/HBASE-5051
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
Attachments: 5051.patch

As it's a new instance, it should be closed. As the function name seems to
imply that it's an instance managed by HBaseTestingUtility, most of the users
don't close it = leak

[jira] [Commented] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call


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

nkeywal commented on HBASE-5051:


TestMasterRestartAfterDisablingTable.testForCheckingIfEnableAndDisableWorksFineAfterSwitch
 = Too many open files
TestReplication.queueFailover = usual flaky test, works locally (just rechecked)
TestInstantSchemaChange.testInstantSchemaJanitor = Too many open files
TestInstantSchemaChange.testInstantSchemaChangeBlocksDuringLoadBalancerRun = 
Too many open files

patch ok imho.

 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.


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

Jonathan Hsieh updated HBASE-4934:
--

Status: Patch Available  (was: Open)

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch, hmaster.png, hregion.png


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.


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

Jonathan Hsieh updated HBASE-4934:
--

Status: Open  (was: Patch Available)

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch, hmaster.png, hregion.png


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.

2011-12-16 Thread jirapos...@reviews.apache.org (Commented) (JIRA)


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

Jonathan Hsieh updated HBASE-4934:
--

Attachment: (was: hbase-4934.patch)

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch, hmaster.png, hregion.png


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006


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

jirapos...@reviews.apache.org commented on HBASE-5049:
--


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3218/#review3948
---

Ship it!


+1

- Michael


On 2011-12-15 23:28:38, Jimmy Xiang wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/3218/
bq.  ---
bq.  
bq.  (Updated 2011-12-15 23:28:38)
bq.  
bq.  
bq.  Review request for hbase, Todd Lipcon, Ted Yu, and Michael Stack.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Minor unit test fix.
bq.  
bq.  
bq.  This addresses bug HBASE-5049.
bq.  https://issues.apache.org/jira/browse/HBASE-5049
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq.src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java 90f9243 
bq.  
bq.  Diff: https://reviews.apache.org/r/3218/diff
bq.  
bq.  
bq.  Testing
bq.  ---
bq.  
bq.  TestHLogSplit works fine in eclipse now.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Jimmy
bq.  
bq.



 TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
 --

 Key: HBASE-5049
 URL: https://issues.apache.org/jira/browse/HBASE-5049
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Attachments: 
 0001-HBASE-5049-TestHLogSplit.testLogRollAfterSplitStart-.patch


 java.lang.IllegalStateException: Can't overwrite cause
   at java.lang.Throwable.initCause(Throwable.java:320)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriter(HLog.java:624)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.createWriterInstance(HLog.java:570)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.rollWriter(HLog.java:504)
   at 
 org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testLogRollAfterSplitStart(TestHLogSplit.java:880)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5055) Build against hadoop 0.22 fails

2011-12-16 Thread Zhihong Yu (Created) (JIRA)

Build against hadoop 0.22 fails
---

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Zhihong Yu
Priority: Blocker


I got the following when compiling TRUNK against hadoop 0.22:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) 
on project hbase: Compilation failure: Compilation failure:
[ERROR] 
/Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
 cannot find symbol
[ERROR] symbol  : class DFSInputStream
[ERROR] location: class org.apache.hadoop.hdfs.DFSClient
[ERROR] 
[ERROR] 
/Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
 cannot find symbol
[ERROR] symbol  : class DFSInputStream
[ERROR] location: class 
org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5055) Build against hadoop 0.22 broken

2011-12-16 Thread Zhihong Yu (Updated) (JIRA)


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

Zhihong Yu updated HBASE-5055:
--

Summary: Build against hadoop 0.22 broken  (was: Build against hadoop 0.22 
fails)

 Build against hadoop 0.22 broken
 

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0
Reporter: Zhihong Yu
Priority: Blocker

 I got the following when compiling TRUNK against hadoop 0.22:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project hbase: Compilation failure: Compilation failure:
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class org.apache.hadoop.hdfs.DFSClient
 [ERROR] 
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5040) Secure HBase builds fail


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

Zhihong Yu commented on HBASE-5040:
---

I think this compilatin error also happens in the build against hadoop 0.22 in 
0.92 branch.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5029) TestDistributedLogSplitting fails on occasion

2011-12-16 Thread Phabricator (Commented) (JIRA)


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

Phabricator commented on HBASE-5029:


stack has accepted the revision HBASE-5029 [jira] TestDistributedLogSplitting 
fails on occasion.

  Thanks for the fix.

REVISION DETAIL
  https://reviews.facebook.net/D891


 TestDistributedLogSplitting fails on occasion
 -

 Key: HBASE-5029
 URL: https://issues.apache.org/jira/browse/HBASE-5029
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Prakash Khemani
 Attachments: HBASE-5029.D891.1.patch, HBASE-5029.D891.2.patch


 This is how it usually fails: 
 https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/
 Assigning mighty Prakash since he offered to take a looksee.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5029) TestDistributedLogSplitting fails on occasion

2011-12-16 Thread Phabricator (Commented) (JIRA)


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

Phabricator commented on HBASE-5029:


stack has commented on the revision HBASE-5029 [jira] 
TestDistributedLogSplitting fails on occasion.

  Post to JIRA and I'll commit.  Good on you Prakash.

REVISION DETAIL
  https://reviews.facebook.net/D891


 TestDistributedLogSplitting fails on occasion
 -

 Key: HBASE-5029
 URL: https://issues.apache.org/jira/browse/HBASE-5029
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Prakash Khemani
 Attachments: HBASE-5029.D891.1.patch, HBASE-5029.D891.2.patch


 This is how it usually fails: 
 https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/
 Assigning mighty Prakash since he offered to take a looksee.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5009) Failure of creating split dir if it already exists prevents splits from happening further


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

Zhihong Yu commented on HBASE-5009:
---

In HBASE-5009.patch, I don't see the call to awaitTermination().
I think we should utilize the timeout for awaitTermination() and throw 
exception if its return value is false.

 Failure of creating split dir if it already exists prevents splits from 
 happening further
 -

 Key: HBASE-5009
 URL: https://issues.apache.org/jira/browse/HBASE-5009
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.6
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-5009.patch, HBASE-5009_Branch90.patch


 The scenario is
 - The split of a region takes a long time
 - The deletion of the splitDir fails due to HDFS problems.
 - Subsequent splits also fail after that.
 {code}
 private static void createSplitDir(final FileSystem fs, final Path splitdir)
   throws IOException {
 if (fs.exists(splitdir)) throw new IOException(Splitdir already exits?  
 + splitdir);
 if (!fs.mkdirs(splitdir)) throw new IOException(Failed create of  + 
 splitdir);
   }
 {code}
 Correct me if am wrong? If it is an issue can we change the behaviour of 
 throwing exception?
 Pls suggest.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4935) hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop


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

stack updated HBASE-4935:
-

Attachment: 4935.txt

This problem shows up when running against local filesystem only.   Its ugly 
when it happens.  I think it important enough to fix.  Mikhail fixed it as part 
of trunk commit of his load tester.  This patch is the piece from that commit 
that addresses the local filesystem problem, a change to SequenceFileLogReader 
only.

 hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop
 ---

 Key: HBASE-4935
 URL: https://issues.apache.org/jira/browse/HBASE-4935
 Project: HBase
  Issue Type: Bug
Reporter: stack
 Attachments: 4935.txt


 See this Mikhail thread up on the list: 
 http://search-hadoop.com/m/WMUZR24EAJ1/%2522SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures%2522subj=Re+SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures
 Dig into it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-4935) hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop

2011-12-16 Thread stack (Resolved) (JIRA)


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

stack resolved HBASE-4935.
--

   Resolution: Fixed
Fix Version/s: 0.92.1
 Assignee: Mikhail Bautin
 Hadoop Flags: Reviewed

Committed to 0.92 branch.  Marking fixed in 0.92.1 for now in case current RC 
passes.  Assigning Mikhail since it his work.

 hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop
 ---

 Key: HBASE-4935
 URL: https://issues.apache.org/jira/browse/HBASE-4935
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Mikhail Bautin
 Fix For: 0.92.1

 Attachments: 4935.txt


 See this Mikhail thread up on the list: 
 http://search-hadoop.com/m/WMUZR24EAJ1/%2522SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures%2522subj=Re+SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures
 Dig into it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5001) Improve the performance of block cache keys

2011-12-16 Thread stack (Commented) (JIRA)


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

stack commented on HBASE-5001:
--

I've been profiling to try and figure the slow down scanning in 0.92 that J-D 
reported up on list and its crazy how much cpu this key making is responsible 
for in the admittedly warped view the profiler gives you.  Let me try this 
patch on 0.92.

 Improve the performance of block cache keys
 ---

 Key: HBASE-5001
 URL: https://issues.apache.org/jira/browse/HBASE-5001
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.94.0

 Attachments: 5001-0.92.txt, 5001-v1.txt, 5001-v2.txt


 Doing a pure random read test on data that's 100% block cache, I see that we 
 are spending quite some time in getBlockCacheKey:
 {quote}
 IPC Server handler 19 on 62023 daemon prio=10 tid=0x7fe0501ff800 
 nid=0x6c87 runnable [0x7fe0577f6000]
java.lang.Thread.State: RUNNABLE
   at java.util.Arrays.copyOf(Arrays.java:2882)
   at 
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
   at 
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
   at java.lang.StringBuilder.append(StringBuilder.java:119)
   at 
 org.apache.hadoop.hbase.io.hfile.HFile.getBlockCacheKey(HFile.java:457)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:249)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.seekToDataBlock(HFileBlockIndex.java:209)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:521)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:536)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:178)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:111)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekExactly(StoreFileScanner.java:219)
   at 
 org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:80)
   at 
 org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1689)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.init(HRegion.java:2857)
 {quote}
 Since the HFile name size is known and the offset is a long, it should be 
 possible to allocate exactly what we need. Maybe use byte[] as the key and 
 drop the separator too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5050) [rest] SPNEGO-based authentication

2011-12-16 Thread Alejandro Abdelnur (Commented) (JIRA)

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

Alejandro Abdelnur commented on HBASE-5050:
---

Hadoop 0.23 onwards has a hadoop-auth artifact that provides SPNEGO/Kerberos
authentication for webapps via a filter. You should consider using it. You
don't have to move Hbase to 0.23 for that, just consume the hadoop-auth
artifact, which has no dependencies on the rest of Hadoop 0.23 artifacts.

[rest] SPNEGO-based authentication
--

Key: HBASE-5050
URL: https://issues.apache.org/jira/browse/HBASE-5050
Project: HBase
Issue Type: Improvement
Components: rest, security
Reporter: Andrew Purtell

Currently the REST gateway can authenticate to a HBase cluster using a
preconfigured principal. This provides a limited form of secure operation
where one or more gateways can be deployed with distinct principals granting
appropriate levels of privilege, but the service ports must be protected
through network ACLs. This is at best a stopgap.
SPNEGO is the standard mechanism for Kerberos authentication over HTTP.
Enhance the REST gateway such that it provides this option, and issues
requests to the HBase cluster with the established context.

[jira] [Commented] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server


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

Zhihong Yu commented on HBASE-4720:
---

The patch is of decent size, can you post on review board so that it is easier 
to correlated comments with code ?
{code}
+ * Copyright 2010 The Apache Software Foundation
{code}
Year isn't needed in license.

Looks like the two new CheckAndXXTableResource classes are cloned off of 
TableResource.java
It would be nice to reuse code from TableResource.java, such as:
{code}
  void scanTransformAttrs() throws IOException {
{code}
Refactoring is always an integral part of new feature.

Thanks for your effort, Mubarak.

 Implement atomic update operations (checkAndPut, checkAndDelete) for REST 
 client/server 
 

 Key: HBASE-4720
 URL: https://issues.apache.org/jira/browse/HBASE-4720
 Project: HBase
  Issue Type: Improvement
Reporter: Daniel Lord
 Attachments: HBASE-4720.v1.patch


 I have several large application/HBase clusters where an application node 
 will occasionally need to talk to HBase from a different cluster.  In order 
 to help ensure some of my consistency guarantees I have a sentinel table that 
 is updated atomically as users interact with the system.  This works quite 
 well for the regular hbase client but the REST client does not implement 
 the checkAndPut and checkAndDelete operations.  This exposes the application 
 to some race conditions that have to be worked around.  It would be ideal if 
 the same checkAndPut/checkAndDelete operations could be supported by the REST 
 client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5050) [rest] SPNEGO-based authentication

2011-12-16 Thread Alejandro Abdelnur (Commented) (JIRA)


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

Alejandro Abdelnur commented on HBASE-5050:
---

You can look at Oozie's trunk which has done this integration already, 
*org.apache.oozie.servlet.AuthFilter*

 [rest] SPNEGO-based authentication
 --

 Key: HBASE-5050
 URL: https://issues.apache.org/jira/browse/HBASE-5050
 Project: HBase
  Issue Type: Improvement
  Components: rest, security
Reporter: Andrew Purtell

 Currently the REST gateway can authenticate to a HBase cluster using a 
 preconfigured principal. This provides a limited form of secure operation 
 where one or more gateways can be deployed with distinct principals granting 
 appropriate levels of privilege, but the service ports must be protected 
 through network ACLs. This is at best a stopgap.
 SPNEGO is the standard mechanism for Kerberos authentication over HTTP. 
 Enhance the REST gateway such that it provides this option, and issues 
 requests to the HBase cluster with the established context.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4940) hadoop-metrics.properties can include configuration of the rest context for ganglia

2011-12-16 Thread Mubarak Seyed (Updated) (JIRA)


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

Mubarak Seyed updated HBASE-4940:
-

Fix Version/s: (was: 0.90.5)
   0.90.6

 hadoop-metrics.properties can include configuration of the rest context for 
 ganglia
 -

 Key: HBASE-4940
 URL: https://issues.apache.org/jira/browse/HBASE-4940
 Project: HBase
  Issue Type: Improvement
  Components: metrics
Affects Versions: 0.90.5
 Environment: HBase-0.90.1
Reporter: Mubarak Seyed
Priority: Minor
  Labels: hbase-rest
 Fix For: 0.90.6

 Attachments: HBASE-4940.patch


 It appears from hadoop-metrics.properties that configuration for rest context 
 is missing. It would be good if we add the rest context and commented out 
 them, if anyone is using rest-server and if they want to monitor using 
 ganglia context then they can uncomment the rest context and use them for 
 rest-server monitoring using ganglia.
 {code}
 # Configuration of the rest context for ganglia
 #rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext
 #rest.period=10
 #rest.servers=ganglia-metad-hostname:port
 {code}
 Working on the patch, will submit it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5001) Improve the performance of block cache keys

2011-12-16 Thread Lars Hofhansl (Commented) (JIRA)


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

Lars Hofhansl commented on HBASE-5001:
--

The 0.92 patch is good go if we decide to use that.

We do almost the same in 0.90, though (minus the _ part), so that would not 
explain the 0.92 slowdown.

 Improve the performance of block cache keys
 ---

 Key: HBASE-5001
 URL: https://issues.apache.org/jira/browse/HBASE-5001
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.94.0

 Attachments: 5001-0.92.txt, 5001-v1.txt, 5001-v2.txt


 Doing a pure random read test on data that's 100% block cache, I see that we 
 are spending quite some time in getBlockCacheKey:
 {quote}
 IPC Server handler 19 on 62023 daemon prio=10 tid=0x7fe0501ff800 
 nid=0x6c87 runnable [0x7fe0577f6000]
java.lang.Thread.State: RUNNABLE
   at java.util.Arrays.copyOf(Arrays.java:2882)
   at 
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
   at 
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
   at java.lang.StringBuilder.append(StringBuilder.java:119)
   at 
 org.apache.hadoop.hbase.io.hfile.HFile.getBlockCacheKey(HFile.java:457)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:249)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.seekToDataBlock(HFileBlockIndex.java:209)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:521)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:536)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:178)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:111)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekExactly(StoreFileScanner.java:219)
   at 
 org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:80)
   at 
 org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1689)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.init(HRegion.java:2857)
 {quote}
 Since the HFile name size is known and the offset is a long, it should be 
 possible to allocate exactly what we need. Maybe use byte[] as the key and 
 drop the separator too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-16 Thread dhruba borthakur (Updated) (JIRA)


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

dhruba borthakur updated HBASE-4938:


Status: Open  (was: Patch Available)

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt, scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-16 Thread dhruba borthakur (Updated) (JIRA)


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

dhruba borthakur updated HBASE-4938:


Status: Patch Available  (was: Open)

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt, scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint

2011-12-16 Thread dhruba borthakur (Updated) (JIRA)


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

dhruba borthakur updated HBASE-4938:


Attachment: scannerMVCC1.txt

Attaching the same patch file again

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt, scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-16 Thread stack (Commented) (JIRA)


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

stack commented on HBASE-5040:
--

I built the secure RC1 passing -DskipTests (didn't want to wait on tests to 
complete).  My fault.  So, whats plan here?  Get 7070 into 1.0.0?  Anyone let 
Matt know?  Should I do it?

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5040) Secure HBase builds fail


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

Zhihong Yu commented on HBASE-5040:
---

See HADOOP-7853
Andy needs a little more time in deciding whether HADOOP-7853 is good enough 
replacement for 7070.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-16 Thread stack (Commented) (JIRA)


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

stack commented on HBASE-5040:
--

OK, I see one of you lads has done it already.  Thanks.  I'll sink the second 
RC.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call


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

Zhihong Yu commented on HBASE-5051:
---

Integrated to TRUNK.

Thanks for the patch, N.

 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4605) Constraints

2011-12-16 Thread Zhihong Yu (Updated) (JIRA)


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

Zhihong Yu updated HBASE-4605:
--

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

 Constraints
 ---

 Key: HBASE-4605
 URL: https://issues.apache.org/jira/browse/HBASE-4605
 Project: HBase
  Issue Type: Improvement
  Components: client, coprocessors
Affects Versions: 0.94.0
Reporter: Jesse Yates
Assignee: Jesse Yates
 Attachments: 4605-v6.txt, 4605.v7, constraint_as_cp.txt, 
 java_Constraint_v2.patch, java_HBASE-4605_v1.patch, java_HBASE-4605_v2.patch, 
 java_HBASE-4605_v3.patch, java_HBASE-4605_v5.patch, java_HBASE-4605_v7.patch


 From Jesse's comment on dev:
 {quote}
 What I would like to propose is a simple interface that people can use to 
 implement a 'constraint' (matching the classic database definition). This 
 would help ease of adoption by helping HBase more easily check that box, help 
 minimize code duplication across organizations, and lead to easier adoption.
 Essentially, people would implement a 'Constraint' interface for checking 
 keys before they are put into a table. Puts that are valid get written to the 
 table, but if not people can will throw an exception that gets propagated 
 back to the client explaining why the put was invalid.
 Constraints would be set on a per-table basis and the user would be expected 
 to ensure the jars containing the constraint are present on the machines 
 serving that table.
 Yes, people could roll their own mechanism for doing this via coprocessors 
 each time, but this would make it easier to do so, so you only have to 
 implement a very minimal interface and not worry about the specifics.
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.

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

Hadoop QA commented on HBASE-4934:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507707/hbase-4934.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

-1 javadoc. The javadoc tool appears to have generated -152 warning
messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 76 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestInstantSchemaChange
org.apache.hadoop.hbase.master.TestDistributedLogSplitting

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/523//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/523//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/523//console

This message is automatically generated.

Display Master server and Regionserver start time on respective info servers.
-

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

Zhihong Yu commented on HBASE-5053:
---

I see some empty lines added by the patch. They should be removed.

For the case of missing connection, I think the log should be at ERROR level.
Also, toString() call isn't needed in the message body:
{code}
+LOG.warn(Connection not found in the list, can't delete it +
+ (connection key=+connectionKey.toString()+));
{code}

HCM Tests leaks connections
---

[jira] [Commented] (HBASE-4934) Display Master server and Regionserver start time on respective info servers.

2011-12-16 Thread Jonathan Hsieh (Commented) (JIRA)


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

Jonathan Hsieh commented on HBASE-4934:
---

I don't think the failed tests are related to this patch at all, there seem to 
be instances of similar failures in the 4-5 previous builds.

 Display Master server and Regionserver start time on respective info servers.
 -

 Key: HBASE-4934
 URL: https://issues.apache.org/jira/browse/HBASE-4934
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Priority: Minor
 Attachments: hbase-4934.patch, hmaster.png, hregion.png


 With operations like rolling restart or master failovers, it is difficult to 
 tell if a server is the old instance or the new restarted instance.  
 Adding a start date stamp on the info web pages would be helpful for 
 determining this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

nkeywal commented on HBASE-5053:

I will update the patch. For the new log line, it can happen today, so it seems
better to put it as a warning? The application will not stop from working, at
least not immediately...

HCM Tests leaks connections
---

[jira] [Updated] (HBASE-5055) Build against hadoop 0.22 broken

2011-12-16 Thread Zhihong Yu (Updated) (JIRA)


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

Zhihong Yu updated HBASE-5055:
--

Affects Version/s: 0.92.0
Fix Version/s: 0.94.0
   0.92.0

 Build against hadoop 0.22 broken
 

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Zhihong Yu
Priority: Blocker
 Fix For: 0.92.0, 0.94.0


 I got the following when compiling TRUNK against hadoop 0.22:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project hbase: Compilation failure: Compilation failure:
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class org.apache.hadoop.hdfs.DFSClient
 [ERROR] 
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5055) Build against hadoop 0.22 broken

2011-12-16 Thread Andrew Purtell (Issue Comment Edited) (JIRA)


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

Zhihong Yu commented on HBASE-5055:
---

Now that HBASE-4935 went into 0.92, I saw the above compilation error in 0.92 
branch as well.
I think this is due to the fact that DFSInputStream is no longer contained in 
DFSClient as of hadoop 0.22

I tried modifying pom.xml to point to the released hadoop 0.22 and had the same 
result.

 Build against hadoop 0.22 broken
 

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Zhihong Yu
Priority: Blocker
 Fix For: 0.92.0, 0.94.0


 I got the following when compiling TRUNK against hadoop 0.22:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project hbase: Compilation failure: Compilation failure:
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class org.apache.hadoop.hdfs.DFSClient
 [ERROR] 
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (HBASE-5040) Secure HBase builds fail


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

Andrew Purtell edited comment on HBASE-5040 at 12/16/11 6:54 PM:
-

Just update the POM to specify Hadoop 1.0.0rc2 in the security profile instead 
of the custom version. That will fix the build issue. HADOOP-7070 is not 
needed, see the comments on HADOOP-7853 and HADOOP-7929.

  was (Author: apurtell):
Just update the POM to specify Hadoop 1.0.0rc2 in the Hadoop profile 
instead of the custom version. That will fix the build issue. HADOOP-7070 is 
not needed, see the comments on HADOOP-7853 and HADOOP-7929.
  
 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5040) Secure HBase builds fail

2011-12-16 Thread Andrew Purtell (Commented) (JIRA)


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

Andrew Purtell commented on HBASE-5040:
---

Just update the POM to specify Hadoop 1.0.0rc2 in the Hadoop profile instead of 
the custom version. That will fix the build issue. HADOOP-7070 is not needed, 
see the comments on HADOOP-7853 and HADOOP-7929.

 Secure HBase builds fail
 

 Key: HBASE-5040
 URL: https://issues.apache.org/jira/browse/HBASE-5040
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Zhihong Yu
 Fix For: 0.92.0


 I saw the following in HBase-0.92-security build #39:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 [ERROR] 
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 [ERROR] - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
 (default-testCompile) on project hbase: Compilation failure
 https://builds.apache.org/job/HBase-0.92-security/ws/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
  method does not override or implement a method from a supertype
 {code}
 The above was probably introduced by HBASE-5006

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5055) Build against hadoop 0.22 broken


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

Zhihong Yu commented on HBASE-5055:
---

Looks like hadoop 0.22 doesn't have HADOOP-7853:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile 
(default-testCompile) on project hbase: Compilation failure
[ERROR] 
/Users/zhihyu/92hbase/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java:[590,4]
 method does not override or implement a method from a supertype
{code}

 Build against hadoop 0.22 broken
 

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Zhihong Yu
Priority: Blocker
 Fix For: 0.92.0, 0.94.0


 I got the following when compiling TRUNK against hadoop 0.22:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project hbase: Compilation failure: Compilation failure:
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class org.apache.hadoop.hdfs.DFSClient
 [ERROR] 
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections


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

Zhihong Yu commented on HBASE-5053:
---

Since the new log line is visible on client side, ERROR would remind them that 
items in Configuation shouldn't be modified.

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4935) hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop


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

stack updated HBASE-4935:
-

Fix Version/s: (was: 0.92.1)
   0.92.0

 hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop
 ---

 Key: HBASE-4935
 URL: https://issues.apache.org/jira/browse/HBASE-4935
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Mikhail Bautin
 Fix For: 0.92.0

 Attachments: 4935.txt


 See this Mikhail thread up on the list: 
 http://search-hadoop.com/m/WMUZR24EAJ1/%2522SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures%2522subj=Re+SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures
 Dig into it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5029) TestDistributedLogSplitting fails on occasion

2011-12-16 Thread Prakash Khemani (Updated) (JIRA)


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

Prakash Khemani updated HBASE-5029:
---

Attachment: 0001-HBASE-5029-jira-TestDistributedLogSplitting-fails-on.patch

 TestDistributedLogSplitting fails on occasion
 -

 Key: HBASE-5029
 URL: https://issues.apache.org/jira/browse/HBASE-5029
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Prakash Khemani
 Attachments: 
 0001-HBASE-5029-jira-TestDistributedLogSplitting-fails-on.patch, 
 HBASE-5029.D891.1.patch, HBASE-5029.D891.2.patch


 This is how it usually fails: 
 https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testWorkerAbort/
 Assigning mighty Prakash since he offered to take a looksee.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Status: Patch Available  (was: Open)

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch, 5053.v2.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Attachment: 5053.v2.patch

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch, 5053.v2.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Status: Open  (was: Patch Available)

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch, 5053.v2.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

nkeywal commented on HBASE-5053:

v2 with Ted's comment taken into account (including error log level) and added
a toString method on connection HConnectionKey.

Tested locally on TestHCM.

HCM Tests leaks connections
---

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections


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

Zhihong Yu commented on HBASE-5053:
---

+1 on patch v2.

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch, 5053.v2.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-4970) Allow better control of resource consumption in HTable (backport HBASE-4805 to 0.90 branch)

2011-12-16 Thread Lars Hofhansl (Commented) (JIRA)

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

Lars Hofhansl commented on HBASE-4970:
--

Thanks for the patch. I'm happy to commit this.

Let's add the new config option to all of 0.90, 0.92.1, and trunk.

Should we still port the slightly bigger change back to 0.90? Is that still
needed for you gaojinchao, or would like to both change integrated in 0.90?

Allow better control of resource consumption in HTable (backport HBASE-4805
to 0.90 branch)
---

Key: HBASE-4970
URL: https://issues.apache.org/jira/browse/HBASE-4970
Project: HBase
Issue Type: Improvement
Components: client
Affects Versions: 0.90.4
Reporter: gaojinchao
Assignee: gaojinchao
Priority: Trivial
Fix For: 0.90.6

Attachments: HBASE-4970_Branch90.patch,
HBASE-4970_Branch90_V1_trial.patch, HBASE-4970_Branch90_V2.patch,
HBASE-4970_Branch92_V2.patch, HBASE-4970_Trunk_V2.patch

In my cluster, I changed keepAliveTime from 60 s to 3600 s. Increasing RES
is slowed down.
Why increasing keepAliveTime of HBase thread pool is slowing down our problem
occurance [RES value increase]?
You can go through the source of sun.nio.ch.Util. Every thread hold 3
softreference of direct buffer(mustangsrc) for reusage. The code names the 3
softreferences buffercache. If the buffer was all occupied or none was
suitable in size, and new request comes, new direct buffer is allocated.
After the service, the bigger one replaces the smaller one in buffercache.
The replaced buffer is released.
So I think we can add a parameter to change keepAliveTime of Htable thread
pool.

[jira] [Created] (HBASE-5056) [performance] On upload

2011-12-16 Thread stack (Created) (JIRA)

[performance] On upload 


 Key: HBASE-5056
 URL: https://issues.apache.org/jira/browse/HBASE-5056
 Project: HBase
  Issue Type: Improvement
Reporter: stack




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-4938) Create a HRegion.getScanner public method that allows reading from a specified readPoint


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

Zhihong Yu commented on HBASE-4938:
---

From https://builds.apache.org/job/PreCommit-HBASE-Build/524/console:
{code}
FATAL: Unable to delete script file /tmp/hudson5668605335506439661.sh
hudson.util.IOException2: remote file operation failed: 
/tmp/hudson5668605335506439661.sh at hudson.remoting.Channel@b3df5d7:hadoop2
at hudson.FilePath.act(FilePath.java:754)
at hudson.FilePath.act(FilePath.java:740)
at hudson.FilePath.delete(FilePath.java:995)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:693)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:459)
at hudson.model.Run.run(Run.java:1376)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:230)
Caused by: hudson.remoting.ChannelClosedException: channel is already closed
at hudson.remoting.Channel.send(Channel.java:499)
{code}
Test suite didn't finish.

 Create a HRegion.getScanner public method that allows reading from a 
 specified readPoint
 

 Key: HBASE-4938
 URL: https://issues.apache.org/jira/browse/HBASE-4938
 Project: HBase
  Issue Type: Improvement
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Priority: Minor
 Attachments: scannerMVCC1.txt, scannerMVCC1.txt


 There is an existing api HRegion.getScanner(Scan) that allows scanning a 
 table. My proposal is to extend it to HRegion.getScanner(Scan, long readPoint)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5056) [performance] On upload, 4% of memory allocations are NullInstance


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

stack updated HBASE-5056:
-

Component/s: performance
Description: Profiling a PE upload, I see that 4% of memory allocations are 
instances of NullInstance (caveat profiler's give distorted view of running app 
as does PE when it comes to real-world workloads).  See attached profiler 
output.  Looks like we could save a bunch on object creation if we had our own 
WritableFactories instance that treated stuff like NullInstance special 
creating a Singleton NullInstance per declared class type returning these 
instead of creating new ones.
Summary: [performance] On upload, 4% of memory allocations are 
NullInstance  (was: [performance] On upload )

 [performance] On upload, 4% of memory allocations are NullInstance
 --

 Key: HBASE-5056
 URL: https://issues.apache.org/jira/browse/HBASE-5056
 Project: HBase
  Issue Type: Improvement
  Components: performance
Reporter: stack
  Labels: noob
 Attachments: NullInstanceHotSpotMemAllocation.html


 Profiling a PE upload, I see that 4% of memory allocations are instances of 
 NullInstance (caveat profiler's give distorted view of running app as does PE 
 when it comes to real-world workloads).  See attached profiler output.  Looks 
 like we could save a bunch on object creation if we had our own 
 WritableFactories instance that treated stuff like NullInstance special 
 creating a Singleton NullInstance per declared class type returning these 
 instead of creating new ones.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5056) [performance] On upload, 4% of memory allocations are NullInstance


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

stack updated HBASE-5056:
-

Attachment: NullInstanceHotSpotMemAllocation.html

 [performance] On upload, 4% of memory allocations are NullInstance
 --

 Key: HBASE-5056
 URL: https://issues.apache.org/jira/browse/HBASE-5056
 Project: HBase
  Issue Type: Improvement
  Components: performance
Reporter: stack
  Labels: noob
 Attachments: NullInstanceHotSpotMemAllocation.html


 Profiling a PE upload, I see that 4% of memory allocations are instances of 
 NullInstance (caveat profiler's give distorted view of running app as does PE 
 when it comes to real-world workloads).  See attached profiler output.  Looks 
 like we could save a bunch on object creation if we had our own 
 WritableFactories instance that treated stuff like NullInstance special 
 creating a Singleton NullInstance per declared class type returning these 
 instead of creating new ones.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5056) [performance] On upload, 4% of memory allocations are NullInstance


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

Zhihong Yu commented on HBASE-5056:
---

+1 on proposed change.

 [performance] On upload, 4% of memory allocations are NullInstance
 --

 Key: HBASE-5056
 URL: https://issues.apache.org/jira/browse/HBASE-5056
 Project: HBase
  Issue Type: Improvement
  Components: performance
Reporter: stack
  Labels: noob
 Attachments: NullInstanceHotSpotMemAllocation.html


 Profiling a PE upload, I see that 4% of memory allocations are instances of 
 NullInstance (caveat profiler's give distorted view of running app as does PE 
 when it comes to real-world workloads).  See attached profiler output.  Looks 
 like we could save a bunch on object creation if we had our own 
 WritableFactories instance that treated stuff like NullInstance special 
 creating a Singleton NullInstance per declared class type returning these 
 instead of creating new ones.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5057) [rest] Upgrade to Jersey 1.8

2011-12-16 Thread Andrew Purtell (Created) (JIRA)

[rest] Upgrade to Jersey 1.8


 Key: HBASE-5057
 URL: https://issues.apache.org/jira/browse/HBASE-5057
 Project: HBase
  Issue Type: Task
Reporter: Andrew Purtell


Hadoop 1.0.0 uses/bundles Jersey version 1.8. Our POM currently specifies 
version 1.4.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5058) Allow HBaseAmin to use an existing connection

2011-12-16 Thread Lars Hofhansl (Created) (JIRA)

Allow HBaseAmin to use an existing connection
-

 Key: HBASE-5058
 URL: https://issues.apache.org/jira/browse/HBASE-5058
 Project: HBase
  Issue Type: Sub-task
  Components: client
Affects Versions: 0.94.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor


What HBASE-4805 does for HTables, this should do for HBaseAdmin.
Along with this the shared error handling and retrying between HBaseAdmin and 
HConnectionManager can also be improved. I'll attach a first pass patch soon.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5056) [performance] On upload, 4% of memory allocations are NullInstance


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

Zhihong Yu commented on HBASE-5056:
---

0.90 has the same code:
{code}
  instanceObj = new NullInstance(declClass, conf);
{code}
So I guess this wouldn't explain the difference in performance.

 [performance] On upload, 4% of memory allocations are NullInstance
 --

 Key: HBASE-5056
 URL: https://issues.apache.org/jira/browse/HBASE-5056
 Project: HBase
  Issue Type: Improvement
  Components: performance
Reporter: stack
  Labels: noob
 Attachments: NullInstanceHotSpotMemAllocation.html


 Profiling a PE upload, I see that 4% of memory allocations are instances of 
 NullInstance (caveat profiler's give distorted view of running app as does PE 
 when it comes to real-world workloads).  See attached profiler output.  Looks 
 like we could save a bunch on object creation if we had our own 
 WritableFactories instance that treated stuff like NullInstance special 
 creating a Singleton NullInstance per declared class type returning these 
 instead of creating new ones.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5059) Tests for: Support deleted rows in CopyTable

2011-12-16 Thread Lars Hofhansl (Created) (JIRA)

Tests for: Support deleted rows in CopyTable


 Key: HBASE-5059
 URL: https://issues.apache.org/jira/browse/HBASE-5059
 Project: HBase
  Issue Type: Sub-task
  Components: mapreduce
Affects Versions: 0.94.0
Reporter: Lars Hofhansl
Priority: Minor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-5059) Tests for: Support deleted rows in CopyTable

2011-12-16 Thread Lars Hofhansl (Assigned) (JIRA)


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

Lars Hofhansl reassigned HBASE-5059:


Assignee: Evan Beard

 Tests for: Support deleted rows in CopyTable
 

 Key: HBASE-5059
 URL: https://issues.apache.org/jira/browse/HBASE-5059
 Project: HBase
  Issue Type: Sub-task
  Components: mapreduce
Affects Versions: 0.94.0
Reporter: Lars Hofhansl
Assignee: Evan Beard
Priority: Minor
 Fix For: 0.94.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5001) Improve the performance of block cache keys

2011-12-16 Thread Konstantin Shvachko (Commented) (JIRA)


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

stack updated HBASE-5001:
-

Fix Version/s: (was: 0.94.0)
   0.92.0

Committed to 0.92 too.. .makes big difference in profiler view.

 Improve the performance of block cache keys
 ---

 Key: HBASE-5001
 URL: https://issues.apache.org/jira/browse/HBASE-5001
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.92.0

 Attachments: 5001-0.92.txt, 5001-v1.txt, 5001-v2.txt


 Doing a pure random read test on data that's 100% block cache, I see that we 
 are spending quite some time in getBlockCacheKey:
 {quote}
 IPC Server handler 19 on 62023 daemon prio=10 tid=0x7fe0501ff800 
 nid=0x6c87 runnable [0x7fe0577f6000]
java.lang.Thread.State: RUNNABLE
   at java.util.Arrays.copyOf(Arrays.java:2882)
   at 
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
   at 
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
   at java.lang.StringBuilder.append(StringBuilder.java:119)
   at 
 org.apache.hadoop.hbase.io.hfile.HFile.getBlockCacheKey(HFile.java:457)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:249)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.seekToDataBlock(HFileBlockIndex.java:209)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:521)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:536)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:178)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:111)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekExactly(StoreFileScanner.java:219)
   at 
 org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:80)
   at 
 org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1689)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.init(HRegion.java:2857)
 {quote}
 Since the HFile name size is known and the offset is a long, it should be 
 possible to allocate exactly what we need. Maybe use byte[] as the key and 
 drop the separator too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call

2011-12-16 Thread Hudson (Commented) (JIRA)


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

Hudson commented on HBASE-5051:
---

Integrated in HBase-TRUNK #2550 (See 
[https://builds.apache.org/job/HBase-TRUNK/2550/])
HBASE-5051 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin 
instance at each call (N Keywal)

tedyu : 
Files : 
* /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/constraint/TestConstraint.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportExport.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/mapreduce/TestLoadIncrementalHFilesSplitRecovery.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/master/TestMaster.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionServerBulkLoad.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestLogRollAbort.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/rest/TestScannersWithFilters.java
* /hbase/trunk/src/test/java/org/apache/hadoop/hbase/rest/TestTableResource.java
* 
/hbase/trunk/src/test/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRebuildTestCore.java


 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5055) Build against hadoop 0.22 broken


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

Konstantin Shvachko commented on HBASE-5055:


It is very unfortunate that HBASE-4935 broke the 0.22 build. Because fixing one 
branch should break another, especially if the latter has been released.
I assume with reflections it shouldn't be hard to fix it to make it work with 
both versions, especially since we know it did work with 0.22 before today's 
commit of HBASE-4935.

 Build against hadoop 0.22 broken
 

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Zhihong Yu
Priority: Blocker
 Fix For: 0.92.0, 0.94.0


 I got the following when compiling TRUNK against hadoop 0.22:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project hbase: Compilation failure: Compilation failure:
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class org.apache.hadoop.hdfs.DFSClient
 [ERROR] 
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5055) Build against hadoop 0.22 broken

2011-12-16 Thread Konstantin Shvachko (Commented) (JIRA)


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

Konstantin Shvachko commented on HBASE-5055:


Correction:
fixing one branch should *NOT* break another

 Build against hadoop 0.22 broken
 

 Key: HBASE-5055
 URL: https://issues.apache.org/jira/browse/HBASE-5055
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.0, 0.94.0
Reporter: Zhihong Yu
Priority: Blocker
 Fix For: 0.92.0, 0.94.0


 I got the following when compiling TRUNK against hadoop 0.22:
 {code}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project hbase: Compilation failure: Compilation failure:
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[37,39]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class org.apache.hadoop.hdfs.DFSClient
 [ERROR] 
 [ERROR] 
 /Users/zhihyu/trunk-hbase/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java:[109,37]
  cannot find symbol
 [ERROR] symbol  : class DFSInputStream
 [ERROR] location: class 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.WALReader.WALReaderFSDataInputStream
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

Hadoop QA commented on HBASE-5053:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507715/5053.v2.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 3 new or modified tests.

-1 javadoc. The javadoc tool appears to have generated -152 warning
messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 76 new Findbugs (version
1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestInstantSchemaChange

org.apache.hadoop.hbase.master.TestMasterRestartAfterDisablingTable

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/525//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/525//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/525//console

This message is automatically generated.

HCM Tests leaks connections
---

[jira] [Updated] (HBASE-5058) Allow HBaseAmin to use an existing connection

2011-12-16 Thread Lars Hofhansl (Updated) (JIRA)


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

Lars Hofhansl updated HBASE-5058:
-

Attachment: 5058.txt

This patch adds an option to use an externally managed HConnection, and also 
simplifies the retry logic in HBaseAdmin.

This is a small change, but please review carefully.

 Allow HBaseAmin to use an existing connection
 -

 Key: HBASE-5058
 URL: https://issues.apache.org/jira/browse/HBASE-5058
 Project: HBase
  Issue Type: Sub-task
  Components: client
Affects Versions: 0.94.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.92.0, 0.94.0

 Attachments: 5058.txt


 What HBASE-4805 does for HTables, this should do for HBaseAdmin.
 Along with this the shared error handling and retrying between HBaseAdmin and 
 HConnectionManager can also be improved. I'll attach a first pass patch soon.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-4935) hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop

2011-12-16 Thread Hudson (Commented) (JIRA)


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

Hudson commented on HBASE-4935:
---

Integrated in HBase-0.92 #191 (See 
[https://builds.apache.org/job/HBase-0.92/191/])
HBASE-4935 hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged 
hadoop

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/wal/SequenceFileLogReader.java


 hbase 0.92.0 doesn't work going against 0.20.205.0, its packaged hadoop
 ---

 Key: HBASE-4935
 URL: https://issues.apache.org/jira/browse/HBASE-4935
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Mikhail Bautin
 Fix For: 0.92.0

 Attachments: 4935.txt


 See this Mikhail thread up on the list: 
 http://search-hadoop.com/m/WMUZR24EAJ1/%2522SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures%2522subj=Re+SequenceFileLogReader+uses+a+reflection+hack+resulting+in+runtime+failures
 Dig into it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5058) Allow HBaseAmin to use an existing connection

2011-12-16 Thread Lars Hofhansl (Updated) (JIRA)


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

Lars Hofhansl updated HBASE-5058:
-

Status: Patch Available  (was: Open)

Test run

 Allow HBaseAmin to use an existing connection
 -

 Key: HBASE-5058
 URL: https://issues.apache.org/jira/browse/HBASE-5058
 Project: HBase
  Issue Type: Sub-task
  Components: client
Affects Versions: 0.94.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.92.0, 0.94.0

 Attachments: 5058.txt


 What HBASE-4805 does for HTables, this should do for HBaseAdmin.
 Along with this the shared error handling and retrying between HBaseAdmin and 
 HConnectionManager can also be improved. I'll attach a first pass patch soon.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5058) Allow HBaseAmin to use an existing connection

2011-12-16 Thread Lars Hofhansl (Updated) (JIRA)


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

Lars Hofhansl updated HBASE-5058:
-

Fix Version/s: (was: 0.92.0)

 Allow HBaseAmin to use an existing connection
 -

 Key: HBASE-5058
 URL: https://issues.apache.org/jira/browse/HBASE-5058
 Project: HBase
  Issue Type: Sub-task
  Components: client
Affects Versions: 0.94.0
Reporter: Lars Hofhansl
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.94.0

 Attachments: 5058.txt


 What HBASE-4805 does for HTables, this should do for HBaseAdmin.
 Along with this the shared error handling and retrying between HBaseAdmin and 
 HConnectionManager can also be improved. I'll attach a first pass patch soon.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5001) Improve the performance of block cache keys

2011-12-16 Thread Lars Hofhansl (Commented) (JIRA)


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

Lars Hofhansl commented on HBASE-5001:
--

Cool :)

 Improve the performance of block cache keys
 ---

 Key: HBASE-5001
 URL: https://issues.apache.org/jira/browse/HBASE-5001
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.92.0

 Attachments: 5001-0.92.txt, 5001-v1.txt, 5001-v2.txt


 Doing a pure random read test on data that's 100% block cache, I see that we 
 are spending quite some time in getBlockCacheKey:
 {quote}
 IPC Server handler 19 on 62023 daemon prio=10 tid=0x7fe0501ff800 
 nid=0x6c87 runnable [0x7fe0577f6000]
java.lang.Thread.State: RUNNABLE
   at java.util.Arrays.copyOf(Arrays.java:2882)
   at 
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
   at 
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
   at java.lang.StringBuilder.append(StringBuilder.java:119)
   at 
 org.apache.hadoop.hbase.io.hfile.HFile.getBlockCacheKey(HFile.java:457)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:249)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.seekToDataBlock(HFileBlockIndex.java:209)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:521)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:536)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:178)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:111)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekExactly(StoreFileScanner.java:219)
   at 
 org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:80)
   at 
 org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1689)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.init(HRegion.java:2857)
 {quote}
 Since the HFile name size is known and the offset is a long, it should be 
 possible to allocate exactly what we need. Maybe use byte[] as the key and 
 drop the separator too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call


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

Zhihong Yu commented on HBASE-5051:
---

TestMasterRestartAfterDisablingTable.testForCheckingIfEnableAndDisableWorksFineAfterSwitch
 failure in TRUNK can be reproduced on MacBook.
Strangely TestMasterRestartAfterDisablingTable didn't appear in the patch.
Could be related to the changes in HMaster.java

Reverting the patch until we determine the root cause.

 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Attachment: 5053.v2.patch

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch, 5053.v2.patch, 5053.v2.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5053) HCM Tests leaks connections


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

nkeywal updated HBASE-5053:
---

Status: Open  (was: Patch Available)

 HCM Tests leaks connections
 ---

 Key: HBASE-5053
 URL: https://issues.apache.org/jira/browse/HBASE-5053
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5053.patch, 5053.v2.patch, 5053.v2.patch


 There are simple leaks and one more complex.
 The complex one comes from the fact fact 
 HConnectionManager.HConnectionImplementation keeps a *reference* to the 
 configuration used for the creation. So if this configuration is updated 
 later, the HConnectionKey created initially will differ from the current one. 
 As a consequence, the close() will not find the connection anymore in the 
 list, and the connection won't be deleted.
 I added a warning when a close does not find the connection in the list; but 
 I wonder if we should not copy the HConnectionKey instead of keeping a 
 reference.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5051) HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each call


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

Zhihong Yu commented on HBASE-5051:
---

I should have double checked: I don't see 'Too many open files' here:
https://builds.apache.org/job/PreCommit-HBASE-Build/521//testReport/org.apache.hadoop.hbase.master/TestMasterRestartAfterDisablingTable/testForCheckingIfEnableAndDisableWorksFineAfterSwitch/

 HBaseTestingUtility#getHBaseAdmin() creates a new HBaseAdmin instance at each 
 call
 --

 Key: HBASE-5051
 URL: https://issues.apache.org/jira/browse/HBASE-5051
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.94.0
Reporter: nkeywal
Assignee: nkeywal
Priority: Minor
 Attachments: 5051.patch


 As it's a new instance, it should be closed. As the function name seems to 
 imply that it's an instance managed by HBaseTestingUtility, most of the users 
 don't close it = leak

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5001) Improve the performance of block cache keys

2011-12-16 Thread Hudson (Commented) (JIRA)


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

Hudson commented on HBASE-5001:
---

Integrated in HBase-0.92 #192 (See 
[https://builds.apache.org/job/HBase-0.92/192/])
HBASE-5001 Improve the performance of block cache keys

stack : 
Files : 
* /hbase/branches/0.92/CHANGES.txt
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockCache.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/CachedBlock.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/DoubleBlockCache.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/SimpleBlockCache.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/slab/SingleSizeCache.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/slab/SlabCache.java
* 
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/io/hfile/slab/SlabItemActionWatcher.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/io/hfile/CacheTestUtils.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCacheOnWrite.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCachedBlockQueue.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/io/hfile/TestLruBlockCache.java


 Improve the performance of block cache keys
 ---

 Key: HBASE-5001
 URL: https://issues.apache.org/jira/browse/HBASE-5001
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.4
Reporter: Jean-Daniel Cryans
Assignee: Lars Hofhansl
Priority: Minor
 Fix For: 0.92.0

 Attachments: 5001-0.92.txt, 5001-v1.txt, 5001-v2.txt


 Doing a pure random read test on data that's 100% block cache, I see that we 
 are spending quite some time in getBlockCacheKey:
 {quote}
 IPC Server handler 19 on 62023 daemon prio=10 tid=0x7fe0501ff800 
 nid=0x6c87 runnable [0x7fe0577f6000]
java.lang.Thread.State: RUNNABLE
   at java.util.Arrays.copyOf(Arrays.java:2882)
   at 
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
   at 
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
   at java.lang.StringBuilder.append(StringBuilder.java:119)
   at 
 org.apache.hadoop.hbase.io.hfile.HFile.getBlockCacheKey(HFile.java:457)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:249)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.seekToDataBlock(HFileBlockIndex.java:209)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:521)
   at 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:536)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:178)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:111)
   at 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekExactly(StoreFileScanner.java:219)
   at 
 org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:80)
   at 
 org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1689)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.init(HRegion.java:2857)
 {quote}
 Since the HFile name size is known and the offset is a long, it should be 
 possible to allocate exactly what we need. Maybe use byte[] as the key and 
 drop the separator too.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

Zhihong Yu commented on HBASE-5053:
---

TestMasterRestartAfterDisablingTable was caused by HBASE-5051 whose changes
were reverted.

Going to commit this patch.

HCM Tests leaks connections
---

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections

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

nkeywal commented on HBASE-5053:

TestInstantSchemaChange = Too many open files
TestMasterRestartAfterDisablingTable = strange, but should be impacted by the
patch. Let's retry to be sure.

HCM Tests leaks connections
---

[jira] [Commented] (HBASE-5053) HCM Tests leaks connections