[jira] [Commented] (HBASE-4532) Avoid top row seek by dedicated bloom filter for delete family bloom filter
[ https://issues.apache.org/jira/browse/HBASE-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133585#comment-13133585 ] Liyin Tang commented on HBASE-4532: --- Thanks Ted:) here is the test results I got. So the testConnectionUniqueness in TestHCM has been fixed now ? == Results : Tests in error: testConnectionUniqueness(org.apache.hadoop.hbase.client.TestHCM) testOrphanLogCreation(org.apache.hadoop.hbase.master.TestDistributedLogSplitting): Unexpected exception, expectedorg.apache.hadoop.hbase.regionserver.wal.OrphanHLogAfterSplitException but wasjava.lang.NullPointerException testOrphanLogCreation(org.apache.hadoop.hbase.master.TestDistributedLogSplitting) testRecoveredEdits(org.apache.hadoop.hbase.master.TestDistributedLogSplitting): /data/users/liyintang/hbase-os-trunk/target/test-data/3d058c80-266a-4164-8143-925d514f016e/09d560d3-254e-4986-abe1-22b876d299f1/4758e332-2ae7-4194-bfea-900ee4a2e3ab/dfs/name1/current/fsimage (Too many open files) testRecoveredEdits(org.apache.hadoop.hbase.master.TestDistributedLogSplitting) testWorkerAbort(org.apache.hadoop.hbase.master.TestDistributedLogSplitting): /data/users/liyintang/hbase-os-trunk/target/test-data/3d058c80-266a-4164-8143-925d514f016e/09d560d3-254e-4986-abe1-22b876d299f1/4758e332-2ae7-4194-bfea-900ee4a2e3ab/3949c75c-8c23-4513-b1cc-e94b1bba640b/dfs/name1/current/fsimage (Too many open files) testWorkerAbort(org.apache.hadoop.hbase.master.TestDistributedLogSplitting) Tests run: 1056, Failures: 0, Errors: 7, Skipped: 9 Avoid top row seek by dedicated bloom filter for delete family bloom filter --- Key: HBASE-4532 URL: https://issues.apache.org/jira/browse/HBASE-4532 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Attachments: D27.1.patch, D27.1.patch, HBASE-4532-apache-trunk.patch, hbase-4532-89-fb.patch The previous jira, HBASE-4469, is to avoid the top row seek operation if row-col bloom filter is enabled. This jira tries to avoid top row seek for all the cases by creating a dedicated bloom filter only for delete family The only subtle use case is when we are interested in the top row with empty column. For example, we are interested in row1/cf1:/1/put. So we seek to the top row: row1/cf1:/MAX_TS/MAXIMUM. And the delete family bloom filter will say there is NO delete family. Then it will avoid the top row seek and return a fake kv, which is the last kv for this row (createLastOnRowCol). In this way, we have already missed the real kv we are interested in. The solution for the above problem is to disable this optimization if we are trying to GET/SCAN a row with empty column. Evaluation from TestSeekOptimization: Previously: For bloom=NONE, compr=NONE total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROW, compr=NONE total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROWCOL, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=NONE, compr=GZ total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROW, compr=GZ total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROWCOL, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% So we can get about 10% more seek savings ONLY if the ROWCOL bloom filter is enabled.[HBASE-4469] After this change: For bloom=NONE, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROW, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROWCOL, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=NONE, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROW, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROWCOL, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% So we can get about 10% more seek savings for ALL kinds of bloom filter. -- 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-4612) Allow ColumnPrefixFilter to support multiple prefixes
[ https://issues.apache.org/jira/browse/HBASE-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eran Kutner updated HBASE-4612: --- Attachment: HBASE-4612.patch Allow ColumnPrefixFilter to support multiple prefixes - Key: HBASE-4612 URL: https://issues.apache.org/jira/browse/HBASE-4612 Project: HBase Issue Type: Improvement Components: filters Affects Versions: 0.90.4 Reporter: Eran Kutner Assignee: Eran Kutner Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4612-0.90.patch, HBASE-4612.patch When having a lot of columns grouped by name I've found that it would be very useful to be able to scan them using multiple prefixes, allowing to fetch specific groups in one scan, without fetching the entire row. This is impossible to achieve using a FilterList, so I've added such support to the existing ColmnPrefixFilter while keeping backward compatibility. The attached patch is based on 0.90.4, I noticed that the 0.92 branch has a new method to support instantiating filters using Thrift. I'm not sure how the serialization works there so I didn't implement that, but the rest of my code should work in 0.92 as well. -- 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-4612) Allow ColumnPrefixFilter to support multiple prefixes
[ https://issues.apache.org/jira/browse/HBASE-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133586#comment-13133586 ] Eran Kutner commented on HBASE-4612: OK, I uploaded a patch for trunk, hopefully what I've done with the createFilterFromArguments method makes sense. Allow ColumnPrefixFilter to support multiple prefixes - Key: HBASE-4612 URL: https://issues.apache.org/jira/browse/HBASE-4612 Project: HBase Issue Type: Improvement Components: filters Affects Versions: 0.90.4 Reporter: Eran Kutner Assignee: Eran Kutner Priority: Minor Fix For: 0.94.0 Attachments: HBASE-4612-0.90.patch, HBASE-4612.patch When having a lot of columns grouped by name I've found that it would be very useful to be able to scan them using multiple prefixes, allowing to fetch specific groups in one scan, without fetching the entire row. This is impossible to achieve using a FilterList, so I've added such support to the existing ColmnPrefixFilter while keeping backward compatibility. The attached patch is based on 0.90.4, I noticed that the 0.92 branch has a new method to support instantiating filters using Thrift. I'm not sure how the serialization works there so I didn't implement that, but the rest of my code should work in 0.92 as well. -- 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-4532) Avoid top row seek by dedicated bloom filter for delete family bloom filter
[ https://issues.apache.org/jira/browse/HBASE-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133599#comment-13133599 ] Ted Yu commented on HBASE-4532: --- TestHCM wasn't fixed. If the test fails consistently, maybe you can help debug it. For the other test failures, it seems ulimit on the machine performing tests has to be increased. Avoid top row seek by dedicated bloom filter for delete family bloom filter --- Key: HBASE-4532 URL: https://issues.apache.org/jira/browse/HBASE-4532 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Attachments: D27.1.patch, D27.1.patch, HBASE-4532-apache-trunk.patch, hbase-4532-89-fb.patch The previous jira, HBASE-4469, is to avoid the top row seek operation if row-col bloom filter is enabled. This jira tries to avoid top row seek for all the cases by creating a dedicated bloom filter only for delete family The only subtle use case is when we are interested in the top row with empty column. For example, we are interested in row1/cf1:/1/put. So we seek to the top row: row1/cf1:/MAX_TS/MAXIMUM. And the delete family bloom filter will say there is NO delete family. Then it will avoid the top row seek and return a fake kv, which is the last kv for this row (createLastOnRowCol). In this way, we have already missed the real kv we are interested in. The solution for the above problem is to disable this optimization if we are trying to GET/SCAN a row with empty column. Evaluation from TestSeekOptimization: Previously: For bloom=NONE, compr=NONE total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROW, compr=NONE total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROWCOL, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=NONE, compr=GZ total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROW, compr=GZ total seeks without optimization: 2506, with optimization: 1714 (68.40%), savings: 31.60% For bloom=ROWCOL, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% So we can get about 10% more seek savings ONLY if the ROWCOL bloom filter is enabled.[HBASE-4469] After this change: For bloom=NONE, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROW, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROWCOL, compr=NONE total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=NONE, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROW, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% For bloom=ROWCOL, compr=GZ total seeks without optimization: 2506, with optimization: 1458 (58.18%), savings: 41.82% So we can get about 10% more seek savings for ALL kinds of bloom filter. -- 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-4648) Bytes.toBigDecimal() doesn't use offset
Bytes.toBigDecimal() doesn't use offset --- Key: HBASE-4648 URL: https://issues.apache.org/jira/browse/HBASE-4648 Project: HBase Issue Type: Bug Components: util Affects Versions: 0.90.4 Environment: Java 1.6.0_26, Mac OS X 10.7 and CentOS 6 Reporter: Bryan Keller The Bytes.toBigDecimal(byte[], offset, len) method does not use the offset, thus you will get an incorrect result for the BigDecimal unless the BigDecimal's bytes are at the beginning of the byte array. -- 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-4528) The put operation can release the rowlock before sync-ing the Hlog
[
https://issues.apache.org/jira/browse/HBASE-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133610#comment-13133610
]
Ted Yu commented on HBASE-4528:
---
From StoreFile.Reader.passesTimerangeFilter():
{code}
public boolean shouldSeek(Scan scan, final SortedSetbyte[] columns) {
return (passesTimerangeFilter(scan) passesBloomFilter(scan, columns));
}
/**
* Check if this storeFile may contain keys within the TimeRange
* @param scan
* @return False if it definitely does not exist in this StoreFile
*/
private boolean passesTimerangeFilter(Scan scan) {
{code}
The put operation can release the rowlock before sync-ing the Hlog
--
Key: HBASE-4528
URL: https://issues.apache.org/jira/browse/HBASE-4528
Project: HBase
Issue Type: Improvement
Components: regionserver
Reporter: dhruba borthakur
Assignee: dhruba borthakur
Fix For: 0.94.0
Attachments: appendNoSync5.txt, appendNoSyncPut1.txt,
appendNoSyncPut2.txt, appendNoSyncPut3.txt, appendNoSyncPut4.txt,
appendNoSyncPut5.txt, appendNoSyncPut6.txt, appendNoSyncPut7.txt,
appendNoSyncPut8.txt
This allows for better throughput when there are hot rows. A single row
update improves from 100 puts/sec/server to 5000 puts/sec/server.
--
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-4552) multi-CF bulk load is not atomic across column families
[ https://issues.apache.org/jira/browse/HBASE-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133677#comment-13133677 ] Jonathan Hsieh commented on HBASE-4552: --- One more piece: Mechanism to atomically rollback if a partial failures encountered when attempting to bulk load multiple families. For example, let's say I want to bulk load a region with cfs A, B, C. I issue a call to an RS region to atomically bulkload the HFiles. The RS loads A and B successfully but fails on C (hdfs failure, or rs goes down, etc). We should rollback A and B -- if we don't we would have A and B loaded but not C and have an atomicity violation. multi-CF bulk load is not atomic across column families --- Key: HBASE-4552 URL: https://issues.apache.org/jira/browse/HBASE-4552 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Jonathan Hsieh Fix For: 0.92.0 Currently the bulk load API simply imports one HFile at a time. With multi-column-family support, this is inappropriate, since different CFs show up separately. Instead, the IPC endpoint should take a of CF - HFiles, so we can online them all under a single region-wide lock. -- 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-4552) multi-CF bulk load is not atomic across column families
[ https://issues.apache.org/jira/browse/HBASE-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133679#comment-13133679 ] Ted Yu commented on HBASE-4552: --- In case of such faulty condition (hdfs failure), would it be easier if we record which column families encountered error and retry loading them after faulty condition recovers ? multi-CF bulk load is not atomic across column families --- Key: HBASE-4552 URL: https://issues.apache.org/jira/browse/HBASE-4552 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Jonathan Hsieh Fix For: 0.92.0 Currently the bulk load API simply imports one HFile at a time. With multi-column-family support, this is inappropriate, since different CFs show up separately. Instead, the IPC endpoint should take a of CF - HFiles, so we can online them all under a single region-wide lock. -- 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-4649) Add atomic bulk load function to region server
Add atomic bulk load function to region server -- Key: HBASE-4649 URL: https://issues.apache.org/jira/browse/HBASE-4649 Project: HBase Issue Type: Sub-task Reporter: Jonathan Hsieh Add a method that atomically bulk load multiple hfiles. Row atomicity guarantees for multi-column family rows require this functionality. -- 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-4649) Add atomic bulk load function to region server
[ https://issues.apache.org/jira/browse/HBASE-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh reassigned HBASE-4649: - Assignee: Jonathan Hsieh Add atomic bulk load function to region server -- Key: HBASE-4649 URL: https://issues.apache.org/jira/browse/HBASE-4649 Project: HBase Issue Type: Sub-task Components: regionserver Reporter: Jonathan Hsieh Assignee: Jonathan Hsieh Fix For: 0.92.0 Add a method that atomically bulk load multiple hfiles. Row atomicity guarantees for multi-column family rows require this functionality. -- 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-4552) multi-CF bulk load is not atomic across column families
[ https://issues.apache.org/jira/browse/HBASE-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133696#comment-13133696 ] Jonathan Hsieh commented on HBASE-4552: --- If we have an hdfs failure, we won't be able to record or update information about what failed. This make me think we need to journal/log the intended atomic actions. Once we have the log, we can act depending on the situation: * If we complete successfully, we remove/invalidate log and carry on. * If we fail (can't write, rs goes down and restarts), we check to see if everything is in. If it isn't we rollback the subset of hfile loads that had happened. If rollback fails, we still have the log, so we can try later or maybe we kill the RS? How about we make this a subtask/follow on jira. The first cut will just detect the situation and log error messages (similar to what currently happens). A follow-on task will discuss and add/implement a recovery mechanism? multi-CF bulk load is not atomic across column families --- Key: HBASE-4552 URL: https://issues.apache.org/jira/browse/HBASE-4552 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Jonathan Hsieh Fix For: 0.92.0 Currently the bulk load API simply imports one HFile at a time. With multi-column-family support, this is inappropriate, since different CFs show up separately. Instead, the IPC endpoint should take a of CF - HFiles, so we can online them all under a single region-wide lock. -- 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-4552) multi-CF bulk load is not atomic across column families
[ https://issues.apache.org/jira/browse/HBASE-4552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133701#comment-13133701 ] Ted Yu commented on HBASE-4552: --- It is fine to implement recovery in another JIRA. multi-CF bulk load is not atomic across column families --- Key: HBASE-4552 URL: https://issues.apache.org/jira/browse/HBASE-4552 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.92.0 Reporter: Todd Lipcon Assignee: Jonathan Hsieh Fix For: 0.92.0 Currently the bulk load API simply imports one HFile at a time. With multi-column-family support, this is inappropriate, since different CFs show up separately. Instead, the IPC endpoint should take a of CF - HFiles, so we can online them all under a single region-wide lock. -- 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-4634) test.build.data property overused leading to write data at the wrong place
[
https://issues.apache.org/jira/browse/HBASE-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nkeywal updated HBASE-4634:
---
Attachment: 20111023_4634_all.v4.patch
Tests ok...
test.build.data property overused leading to write data at the wrong place
Key: HBASE-4634
URL: https://issues.apache.org/jira/browse/HBASE-4634
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 0.92.0
Environment: all
Reporter: nkeywal
Assignee: nkeywal
Attachments: 2011020_4634_all.patch,
20111020_4639_TestStoreFile.patch, 20111021_4634_all.v2.patch,
20111022_4634_all.v3.patch, 20111023_4634_all.v4.patch
test.build.data is overloaded in HBase.At the beginning, it's the Default
parent directory for test output., but then it's rewritten to be the
directory itself in functions like HBaseTestingUtility#startMiniDFSCluster
It seems that this value is already used by MiniDFS (i.e. outside of HBase):
Name is as it is because mini dfs has hard-codings to put test data here.
As it is today, there is at least a bug in HBaseTestingUtility:
{noformat}
public void initTestDir() {
if (System.getProperty(TEST_DIRECTORY_KEY) == null) {
clusterTestBuildDir = setupClusterTestBuildDir();
System.setProperty(TEST_DIRECTORY_KEY, clusterTestBuildDir.getPath());
}
}
{noformat}
if you set a value for test.build.data, the test dir will be the parent
directory and not a temp subdir, leading to issues as multiple tests will
end-ups in the same (bad) directory. This function is barely used today,
hence it's not visible, but I would like to use it in some new code.
A possible fix is to remove the check for null and continue with the
overloading, but I don't think it would be a big issue to create a new
key(like test.build.data.rootdirectory) specific to the root directory and
to use test.build.data only to communicate with MiniDFS. Feedback welcome.
--
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-4647) RAT finds about 40 files missing licenses
[ https://issues.apache.org/jira/browse/HBASE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133744#comment-13133744 ] stack commented on HBASE-4647: -- Just to say that the 'mvn rat:check' was barfing because too many bad files and that it turns out our build of site actually generates the rat report. You can see it here: http://hbase.apache.org/rat-report.html RAT finds about 40 files missing licenses - Key: HBASE-4647 URL: https://issues.apache.org/jira/browse/HBASE-4647 Project: HBase Issue Type: Bug Reporter: stack Priority: Blocker Attachments: licenses.txt Giri is trying to hook up the patch build. We need to pass the RAT tool. I ran it, http://incubator.apache.org/rat/index.html, and found about 40 files missing licenses (and about 5 purely empty files). -- 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-4647) RAT finds about 40 files missing licenses
[ https://issues.apache.org/jira/browse/HBASE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4647. -- Resolution: Fixed Fix Version/s: 0.92.0 Assignee: stack Checked out UI, packaging, and site as well as tests. Seems fine so committed to TRUNK and 0.92. RAT finds about 40 files missing licenses - Key: HBASE-4647 URL: https://issues.apache.org/jira/browse/HBASE-4647 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.92.0 Attachments: licenses.txt Giri is trying to hook up the patch build. We need to pass the RAT tool. I ran it, http://incubator.apache.org/rat/index.html, and found about 40 files missing licenses (and about 5 purely empty files). -- 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-4447) Allow hbase.version to be passed in as command-line argument
[
https://issues.apache.org/jira/browse/HBASE-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133765#comment-13133765
]
stack commented on HBASE-4447:
--
@Joep I'm going to revert this change (See Eric's input above). I also see
that when you build with mvn 3 it complains:
{code}
pynchon-645:clean-trunk stack$ ~/bin/apache-maven-3.0.3/bin/mvn apache-rat:rat
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase:jar:0.93-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. @
org.apache.hbase:hbase:${hbase.version},
/Users/stack/checkout/clean-trunk/pom.xml, line 40, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{code}
You ok with using the versions plugin as per Eric above?
Allow hbase.version to be passed in as command-line argument
Key: HBASE-4447
URL: https://issues.apache.org/jira/browse/HBASE-4447
Project: HBase
Issue Type: Improvement
Components: build
Affects Versions: 0.92.0
Reporter: Joep Rottinghuis
Assignee: Joep Rottinghuis
Fix For: 0.92.0
Attachments: HBASE-4447-0.92.patch
Currently the build always produces the jars and tarball according to the
version baked into the POM.
When we modify this to allow the version to be passed in as a command-line
argument, it can still default to the same behavior, yet give the flexibility
for an internal build to tag on own version.
--
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-4642) Add Apache License Header
[ https://issues.apache.org/jira/browse/HBASE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4642: - Attachment: 4642.txt Updates apache-rat-plugin to 0.7 from 0.6 (Run it with mvn 3 and do apache-rat:check). Added a few more licenses and a set of excludes -- exclude target/**, .*, etc. Passes now. Add Apache License Header -- Key: HBASE-4642 URL: https://issues.apache.org/jira/browse/HBASE-4642 Project: HBase Issue Type: Improvement Reporter: Giridharan Kesavan Attachments: 4642.txt, ratswarnings.txt executing mvn apache-rat:check fails with [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.6:check (default-cli) on project hbase: Too many unapproved licenses: 84 - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.rat:apache-rat-plugin:0.6:check (default-cli) on project hbase: Too many unapproved licenses: 84 there are about 70 + files which are missing the Apache License Headers and rest of them should be added to the exclude list. -- 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-4642) Add Apache License Header
[ https://issues.apache.org/jira/browse/HBASE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4642. -- Resolution: Fixed Fix Version/s: 0.92.0 Assignee: stack Applied patch to 0.92 branch and to trunk. Add Apache License Header -- Key: HBASE-4642 URL: https://issues.apache.org/jira/browse/HBASE-4642 Project: HBase Issue Type: Improvement Reporter: Giridharan Kesavan Assignee: stack Fix For: 0.92.0 Attachments: 4642.txt, ratswarnings.txt executing mvn apache-rat:check fails with [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.6:check (default-cli) on project hbase: Too many unapproved licenses: 84 - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.rat:apache-rat-plugin:0.6:check (default-cli) on project hbase: Too many unapproved licenses: 84 there are about 70 + files which are missing the Apache License Headers and rest of them should be added to the exclude list. -- 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-4447) Allow hbase.version to be passed in as command-line argument
[ https://issues.apache.org/jira/browse/HBASE-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-4447. -- Resolution: Fixed I reverted this change. Closing. Allow hbase.version to be passed in as command-line argument Key: HBASE-4447 URL: https://issues.apache.org/jira/browse/HBASE-4447 Project: HBase Issue Type: Improvement Components: build Affects Versions: 0.92.0 Reporter: Joep Rottinghuis Assignee: Joep Rottinghuis Fix For: 0.92.0 Attachments: HBASE-4447-0.92.patch Currently the build always produces the jars and tarball according to the version baked into the POM. When we modify this to allow the version to be passed in as a command-line argument, it can still default to the same behavior, yet give the flexibility for an internal build to tag on own version. -- 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-4447) Allow hbase.version to be passed in as command-line argument
[ https://issues.apache.org/jira/browse/HBASE-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133780#comment-13133780 ] Jonathan Gray commented on HBASE-4447: -- Shouldn't be fixed? Should be Invalid or some other? Thanks for all the cleanup stack! Allow hbase.version to be passed in as command-line argument Key: HBASE-4447 URL: https://issues.apache.org/jira/browse/HBASE-4447 Project: HBase Issue Type: Improvement Components: build Affects Versions: 0.92.0 Reporter: Joep Rottinghuis Assignee: Joep Rottinghuis Fix For: 0.92.0 Attachments: HBASE-4447-0.92.patch Currently the build always produces the jars and tarball according to the version baked into the POM. When we modify this to allow the version to be passed in as a command-line argument, it can still default to the same behavior, yet give the flexibility for an internal build to tag on own version. -- 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-4647) RAT finds about 40 files missing licenses
[ https://issues.apache.org/jira/browse/HBASE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133782#comment-13133782 ] Hudson commented on HBASE-4647: --- Integrated in HBase-TRUNK #2359 (See [https://builds.apache.org/job/HBase-TRUNK/2359/]) HBASE-4647 RAT finds about 40 files missing licenses stack : Files : * /hbase/trunk/CHANGES.txt * /hbase/trunk/bin/copy_table.rb * /hbase/trunk/pom.xml * /hbase/trunk/src/assembly/all.xml * /hbase/trunk/src/docbkx/configuration.xml * /hbase/trunk/src/docbkx/developer.xml * /hbase/trunk/src/docbkx/external_apis.xml * /hbase/trunk/src/docbkx/getting_started.xml * /hbase/trunk/src/docbkx/ops_mgt.xml * /hbase/trunk/src/docbkx/performance.xml * /hbase/trunk/src/docbkx/preface.xml * /hbase/trunk/src/docbkx/shell.xml * /hbase/trunk/src/docbkx/troubleshooting.xml * /hbase/trunk/src/docbkx/upgrading.xml * /hbase/trunk/src/examples/mapreduce/index-builder-setup.rb * /hbase/trunk/src/main/avro/hbase.avpr * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/avro/hbase.genavro * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/filter/TimestampsFilter.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/io/WritableDelayed.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheableDeserializer.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/mapreduce/TsvImporterMapper.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/RegionPlan.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/master/ServerAndLoad.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/util/FSNonHDFSUtils.java * /hbase/trunk/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKTableDisable.java * /hbase/trunk/src/main/javadoc/org/apache/hadoop/hbase/thrift/doc-files/Hbase.html * /hbase/trunk/src/main/javadoc/org/apache/hadoop/hbase/thrift/doc-files/index.html * /hbase/trunk/src/main/javadoc/org/apache/hadoop/hbase/thrift/doc-files/style.css * /hbase/trunk/src/main/resources/hbase-default.xml * /hbase/trunk/src/main/resources/hbase-webapps/master/index.html * /hbase/trunk/src/main/resources/hbase-webapps/master/master.jsp * /hbase/trunk/src/main/resources/hbase-webapps/master/table.jsp * /hbase/trunk/src/main/resources/hbase-webapps/master/tablesDetailed.jsp * /hbase/trunk/src/main/resources/hbase-webapps/master/zk.jsp * /hbase/trunk/src/main/resources/hbase-webapps/regionserver/index.html * /hbase/trunk/src/main/resources/hbase-webapps/regionserver/regionserver.jsp * /hbase/trunk/src/main/resources/hbase-webapps/static/hbase.css * /hbase/trunk/src/main/resources/org/apache/hadoop/hbase/mapred/RowCounter_Counters.properties * /hbase/trunk/src/main/resources/org/apache/hadoop/hbase/mapreduce/RowCounter_Counters.properties * /hbase/trunk/src/main/resources/org/apache/hadoop/hbase/rest/XMLSchema.xsd * /hbase/trunk/src/packages/deb/conf-pseudo.control/conffile * /hbase/trunk/src/packages/deb/hbase.control/control * /hbase/trunk/src/site/site.vm * /hbase/trunk/src/site/site.xml * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/TestHServerInfo.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/coprocessor/GenericEndpoint.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/coprocessor/GenericProtocol.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/filter/TestColumnPrefixFilter.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/filter/TestColumnRangeFilter.java * /hbase/trunk/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestLogRollAbort.java * /hbase/trunk/src/test/resources/log4j.properties * /hbase/trunk/src/test/resources/mapred-queues.xml * /hbase/trunk/src/test/ruby/test_helper.rb RAT finds about 40 files missing licenses - Key: HBASE-4647 URL: https://issues.apache.org/jira/browse/HBASE-4647 Project: HBase Issue Type: Bug Reporter: stack Assignee: stack Priority: Blocker Fix For: 0.92.0 Attachments: licenses.txt Giri is trying to hook up the patch build. We need to pass the RAT tool. I ran it, http://incubator.apache.org/rat/index.html, and found about 40 files missing licenses (and about 5 purely empty files). -- 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-4447) Allow hbase.version to be passed in as command-line argument
[ https://issues.apache.org/jira/browse/HBASE-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133789#comment-13133789 ] Hudson commented on HBASE-4447: --- Integrated in HBase-TRUNK #2360 (See [https://builds.apache.org/job/HBase-TRUNK/2360/]) HBASE-4447 Allow hbase.version to be passed in as command-line argument; REVERTsvn diffsvn diff stack : Files : * /hbase/trunk/pom.xml Allow hbase.version to be passed in as command-line argument Key: HBASE-4447 URL: https://issues.apache.org/jira/browse/HBASE-4447 Project: HBase Issue Type: Improvement Components: build Affects Versions: 0.92.0 Reporter: Joep Rottinghuis Assignee: Joep Rottinghuis Fix For: 0.92.0 Attachments: HBASE-4447-0.92.patch Currently the build always produces the jars and tarball according to the version baked into the POM. When we modify this to allow the version to be passed in as a command-line argument, it can still default to the same behavior, yet give the flexibility for an internal build to tag on own version. -- 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-4642) Add Apache License Header
[ https://issues.apache.org/jira/browse/HBASE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133790#comment-13133790 ] Hudson commented on HBASE-4642: --- Integrated in HBase-TRUNK #2360 (See [https://builds.apache.org/job/HBase-TRUNK/2360/]) HBASE-4642 Add Apache License Header stack : Files : * /hbase/trunk/CHANGES.txt * /hbase/trunk/bin/local-master-backup.sh * /hbase/trunk/bin/local-regionservers.sh * /hbase/trunk/bin/set_meta_block_caching.rb * /hbase/trunk/bin/set_meta_memstore_size.rb * /hbase/trunk/pom.xml Add Apache License Header -- Key: HBASE-4642 URL: https://issues.apache.org/jira/browse/HBASE-4642 Project: HBase Issue Type: Improvement Reporter: Giridharan Kesavan Assignee: stack Fix For: 0.92.0 Attachments: 4642.txt, ratswarnings.txt executing mvn apache-rat:check fails with [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.6:check (default-cli) on project hbase: Too many unapproved licenses: 84 - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.rat:apache-rat-plugin:0.6:check (default-cli) on project hbase: Too many unapproved licenses: 84 there are about 70 + files which are missing the Apache License Headers and rest of them should be added to the exclude list. -- 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-4651) TestHCM case fails(ConcurrentModificationException might be thrown in TestHCM.testConnectionUniqueness)
[
https://issues.apache.org/jira/browse/HBASE-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gaojinchao reassigned HBASE-4651:
-
Assignee: gaojinchao
TestHCM case fails(ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness)
---
Key: HBASE-4651
URL: https://issues.apache.org/jira/browse/HBASE-4651
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: gaojinchao
Assignee: gaojinchao
Priority: Minor
Fix For: 0.92.0
looks Ted's mail
ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness.
See
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness
363 EntryK,V nextEntry() {
364 if (modCount != expectedModCount)
365 throw new
ConcurrentModificationExceptionhttp://kickjava.com/src/java/util/ConcurrentModificationException.java.htm
[image:
JavaDoc] http://kickjava.com/2487.htm();
Read more:
http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT
HCM uses proper synchronization when accessing HBASE_INSTANCES.
Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES in a
Set and returns the size of the Set.
However, post HBASE-3777, the values (HConnectionImplementation's) in
HBASE_INSTANCES would be unique.
I simplified TestHCM.getValidKeyCount() by returning cache.size() directly
where ConcurrentModificationException isn't thrown.
The test passed.
Please comment on proposed simplification.
--
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-4651) TestHCM case fails(ConcurrentModificationException might be thrown in TestHCM.testConnectionUniqueness)
TestHCM case fails(ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness)
---
Key: HBASE-4651
URL: https://issues.apache.org/jira/browse/HBASE-4651
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: gaojinchao
Priority: Minor
Fix For: 0.92.0
looks Ted's mail
ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness.
See
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness
363 EntryK,V nextEntry() {
364 if (modCount != expectedModCount)
365 throw new
ConcurrentModificationExceptionhttp://kickjava.com/src/java/util/ConcurrentModificationException.java.htm
[image:
JavaDoc] http://kickjava.com/2487.htm();
Read more:
http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT
HCM uses proper synchronization when accessing HBASE_INSTANCES.
Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES in a
Set and returns the size of the Set.
However, post HBASE-3777, the values (HConnectionImplementation's) in
HBASE_INSTANCES would be unique.
I simplified TestHCM.getValidKeyCount() by returning cache.size() directly
where ConcurrentModificationException isn't thrown.
The test passed.
Please comment on proposed simplification.
--
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-4508) Backport HBASE-3777 to 0.90 branch
[ https://issues.apache.org/jira/browse/HBASE-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bright Fulton updated HBASE-4508: - Attachment: HBASE-4508.v5.patch Remove TestHCM.getValidKeyCount() from patch to avoid ConcurrentModificationException: testConnectionUniqueness(org.apache.hadoop.hbase.client.TestHCM) Time elapsed: 1.978 sec ERROR! java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:373) at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:384) at java.util.AbstractCollection.toArray(AbstractCollection.java:124) at java.util.ArrayList.init(ArrayList.java:131) at org.apache.hadoop.hbase.client.TestHCM.getValidKeyCount(TestHCM.java:136) at org.apache.hadoop.hbase.client.TestHCM.testConnectionUniqueness(TestHCM.java:222) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Based on revision 1188010. Backport HBASE-3777 to 0.90 branch -- Key: HBASE-4508 URL: https://issues.apache.org/jira/browse/HBASE-4508 Project: HBase Issue Type: Bug Reporter: Ted Yu Assignee: Bright Fulton Fix For: 0.90.5 Attachments: HBASE-4508.v1.patch, HBASE-4508.v2.patch, HBASE-4508.v3.patch, HBASE-4508.v4.git.patch, HBASE-4508.v4.patch, HBASE-4508.v5.patch See discussion here: http://search-hadoop.com/m/MJBId1aazTR1/backporting+HBASE-3777+to+0.90subj=backporting+HBASE+3777+to+0+90 Rocketfuel has been running 0.90.3 with HBASE-3777 since its resolution. They have 10 RS nodes , 1 Master and 1 Zookeeper Live writes and reads but super heavy on reads. Cache hit is pretty high. The qps on one of their data centers is 50K. -- 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-4651) ConcurrentModificationException might be thrown in TestHCM.testConnectionUniqueness
[
https://issues.apache.org/jira/browse/HBASE-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-4651:
--
Description:
See
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness
363 EntryK,V nextEntry() {
364 if (modCount != expectedModCount)
365 throw new
ConcurrentModificationExceptionhttp://kickjava.com/src/java/util/ConcurrentModificationException.java.htm
[image:
JavaDoc] http://kickjava.com/2487.htm();
Read more:
http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT
HCM uses proper synchronization when accessing HBASE_INSTANCES.
Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES in a
Set and returns the size of the Set.
However, post HBASE-3777, the values (HConnectionImplementation's) in
HBASE_INSTANCES would be unique.
TestHCM.getValidKeyCount() can be removed from the test.
was:
looks Ted's mail
ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness.
See
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness
363 EntryK,V nextEntry() {
364 if (modCount != expectedModCount)
365 throw new
ConcurrentModificationExceptionhttp://kickjava.com/src/java/util/ConcurrentModificationException.java.htm
[image:
JavaDoc] http://kickjava.com/2487.htm();
Read more:
http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT
HCM uses proper synchronization when accessing HBASE_INSTANCES.
Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES in a
Set and returns the size of the Set.
However, post HBASE-3777, the values (HConnectionImplementation's) in
HBASE_INSTANCES would be unique.
I simplified TestHCM.getValidKeyCount() by returning cache.size() directly
where ConcurrentModificationException isn't thrown.
The test passed.
Please comment on proposed simplification.
Summary: ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness (was: TestHCM case
fails(ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness))
ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness
---
Key: HBASE-4651
URL: https://issues.apache.org/jira/browse/HBASE-4651
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: gaojinchao
Assignee: gaojinchao
Priority: Minor
Fix For: 0.92.0
See
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness
363 EntryK,V nextEntry() {
364 if (modCount != expectedModCount)
365 throw new
ConcurrentModificationExceptionhttp://kickjava.com/src/java/util/ConcurrentModificationException.java.htm
[image:
JavaDoc] http://kickjava.com/2487.htm();
Read more:
http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT
HCM uses proper synchronization when accessing HBASE_INSTANCES.
Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES in a
Set and returns the size of the Set.
However, post HBASE-3777, the values (HConnectionImplementation's) in
HBASE_INSTANCES would be unique.
TestHCM.getValidKeyCount() can be removed from the test.
--
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-4651) ConcurrentModificationException might be thrown in TestHCM.testConnectionUniqueness
[
https://issues.apache.org/jira/browse/HBASE-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133823#comment-13133823
]
Ted Yu commented on HBASE-4651:
---
+1 on patch.
ConcurrentModificationException might be thrown in
TestHCM.testConnectionUniqueness
---
Key: HBASE-4651
URL: https://issues.apache.org/jira/browse/HBASE-4651
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: gaojinchao
Assignee: gaojinchao
Priority: Minor
Fix For: 0.92.0
Attachments: HBASE-4651_Trunk.patch
See
https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/2357/testReport/junit/org.apache.hadoop.hbase.client/TestHCM/testConnectionUniqueness
363 EntryK,V nextEntry() {
364 if (modCount != expectedModCount)
365 throw new
ConcurrentModificationExceptionhttp://kickjava.com/src/java/util/ConcurrentModificationException.java.htm
[image:
JavaDoc] http://kickjava.com/2487.htm();
Read more:
http://kickjava.com/src/java/util/LinkedHashMap.java.htm#ixzz1bbCC0gaT
HCM uses proper synchronization when accessing HBASE_INSTANCES.
Looking at TestHCM.getValidKeyCount(), it puts values of HBASE_INSTANCES in a
Set and returns the size of the Set.
However, post HBASE-3777, the values (HConnectionImplementation's) in
HBASE_INSTANCES would be unique.
TestHCM.getValidKeyCount() can be removed from the test.
--
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
