[jira] [Created] (HBASE-5845) Single Put should use RetriesExhaustedWithDetailsException in case any exception
Single Put should use RetriesExhaustedWithDetailsException in case any exception Key: HBASE-5845 URL: https://issues.apache.org/jira/browse/HBASE-5845 Project: HBase Issue Type: Bug Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Due to change in HBASE-5824. Put has to exception paths now. It's better to stay the same for easy exception handling. -- 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-5785) Adding unit tests for protbuf utils introduced for HRegionInterface pb conversion
Adding unit tests for protbuf utils introduced for HRegionInterface pb conversion - Key: HBASE-5785 URL: https://issues.apache.org/jira/browse/HBASE-5785 Project: HBase Issue Type: Sub-task Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 We need to add some unit tests for the probuf utilities to catch issues earlier. -- 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-5777) MiniHBaseCluster cannot start multiple region servers
MiniHBaseCluster cannot start multiple region servers - Key: HBASE-5777 URL: https://issues.apache.org/jira/browse/HBASE-5777 Project: HBase Issue Type: Test Reporter: Jimmy Xiang MiniHBaseCluster can try to start multiple region servers. But all of them except one will die in putting up the web UI because of BindException since HConstants.REGIONSERVER_INFO_PORT_AUTO is set to false by default. This issue will make many unit tests depends on multiple region servers flaky, such as TestAdmin. -- 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-5759) HBaseClient throws NullPointerException when EOFException should be used.
HBaseClient throws NullPointerException when EOFException should be used. - Key: HBASE-5759 URL: https://issues.apache.org/jira/browse/HBASE-5759 Project: HBase Issue Type: Bug Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Trivial Attachments: hbase-5759.patch When a RPC data input stream is closed, protobuf doesn't raise an EOFException, it returns a null RpcResponse object. We need to check if the response is null before trying to access 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] [Created] (HBASE-5740) Compaction interruption may be due to balacing
Compaction interruption may be due to balacing -- Key: HBASE-5740 URL: https://issues.apache.org/jira/browse/HBASE-5740 Project: HBase Issue Type: Bug Affects Versions: 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Trivial Fix For: 0.96.0 Attachments: hbase-5740.patch Currently, the log shows Aborting compaction of store LOG in region CCS_ACCOUNT_LOG_HBASE02_01,scm01 IDNWNoA0002765 00061395804,1328855408473.8b68adefea8dbc8c77a97ce88cf657a6. because user requested stop. But it is actually because of balancing. Currently, there is no way to figure out who closed the region. So it is better to change the message to say it is because of user, or balancing. -- 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-5734) Change hbck sideline root
Change hbck sideline root - Key: HBASE-5734 URL: https://issues.apache.org/jira/browse/HBASE-5734 Project: HBase Issue Type: Improvement Affects Versions: 0.94.0, 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Trivial Fix For: 0.96.0 Currently hbck sideline root is the root which can run into permission issue. We can change it to /hbck -- 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-5719) Enhance hbck to sideline overlapped mega regions
Enhance hbck to sideline overlapped mega regions Key: HBASE-5719 URL: https://issues.apache.org/jira/browse/HBASE-5719 Project: HBase Issue Type: New Feature Components: hbck Affects Versions: 0.94.0, 0.96.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 If there are too many regions in one overlapped group (by default, more than 10), hbck currently doesn't merge them since it takes time. In this case, we can sideline some regions in the group and break the overlapping to fix the inconsistency. Later on, sidelined regions can be bulk loaded manually. -- 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-5619) Create PB protocols for HRegionInterface
Create PB protocols for HRegionInterface Key: HBASE-5619 URL: https://issues.apache.org/jira/browse/HBASE-5619 Project: HBase Issue Type: Sub-task Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.0 Subtask of HBase-5443, separate HRegionInterface into admin protocol and client protocol, create the PB protocol buffer 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] [Created] (HBASE-5620) Convert the client protocol of HRegionInterface to PB
Convert the client protocol of HRegionInterface to PB - Key: HBASE-5620 URL: https://issues.apache.org/jira/browse/HBASE-5620 Project: HBase Issue Type: Sub-task Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.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] [Created] (HBASE-5621) Convert admin protocol of HRegionInterface to PB
Convert admin protocol of HRegionInterface to PB Key: HBASE-5621 URL: https://issues.apache.org/jira/browse/HBASE-5621 Project: HBase Issue Type: Sub-task Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.96.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] [Created] (HBASE-5410) Deprecate check_meta.rb
Deprecate check_meta.rb --- Key: HBASE-5410 URL: https://issues.apache.org/jira/browse/HBASE-5410 Project: HBase Issue Type: Task Reporter: Jimmy Xiang Priority: Trivial We should depreate check_meta.rb and suggest users to use hbck instead. hbck should give more accurate region hole information. Should we remove check_meta.rb in 92 and 94? -- 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-5398) HBase shell disable_all/enable_all/drop_all promp wrong tables for confirmation
HBase shell disable_all/enable_all/drop_all promp wrong tables for confirmation --- Key: HBASE-5398 URL: https://issues.apache.org/jira/browse/HBASE-5398 Project: HBase Issue Type: Bug Components: scripts Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Fix For: 0.94.0, 0.92.0 When using hbase shell to disable_all/enable_all/drop_all tables, the tables prompted for confirmation are wrong. For example, disable_all 'test*' will show confirmation for diable tables like: mytest1 test123 Fortunately, these tables will not be disable actually since Java pattern doesn't match this way. -- 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-5376) Add more logging to triage HBASE-5312: Closed parent region present in Hlog.lastSeqWritten
Add more logging to triage HBASE-5312: Closed parent region present in Hlog.lastSeqWritten -- Key: HBASE-5376 URL: https://issues.apache.org/jira/browse/HBASE-5376 Project: HBase Issue Type: Sub-task Reporter: Jimmy Xiang Priority: Minor It is hard to find out what exactly caused HBASE-5312. Some logging will be helpful to shine some lights. -- 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-5324) Hbck fix dryrun/plan
Hbck fix dryrun/plan - Key: HBASE-5324 URL: https://issues.apache.org/jira/browse/HBASE-5324 Project: HBase Issue Type: New Feature Components: hbck Affects Versions: 0.94.0 Reporter: Jimmy Xiang Hbck fix should have a dryrun option, or show the planed operations/steps at first, then start the actual fix after confirmed by the user. -- 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-5310) HConnectionManager cache server name enhancement
HConnectionManager cache server name enhancement Key: HBASE-5310 URL: https://issues.apache.org/jira/browse/HBASE-5310 Project: HBase Issue Type: Improvement Components: client Affects Versions: 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.94.0 Attachments: hbase-5310.txt HConnectionManager uses deprecated HServerAddress to create server cache key which needs to resolve the address every time. It should be better to use HRegionLocation.getHostnamePort() instead. In our cluster we have some DNS issue, resolving an address fails sometime which kills the application since it is a runtime exception IllegalArgumentException thrown at HServerAddress.getResolvedAddress. This change will fix this issue 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] [Created] (HBASE-5239) Suppress hbase file or dir doesn't exist warning
Suppress hbase file or dir doesn't exist warning Key: HBASE-5239 URL: https://issues.apache.org/jira/browse/HBASE-5239 Project: HBase Issue Type: Improvement Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Trivial I got these warnings in running hbase shell. It causes some confusion. I think it is safe to suppress them. ls: cannot access .../hadoop-common*.jar: No such file or directory ls: cannot access .../hadoop-hdfs*.jar: No such file or directory ls: cannot access .../hadoop-mapred*.jar: No such file or directory -- 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-5196) Failure in region split after PONR could cause region hole
Failure in region split after PONR could cause region hole -- Key: HBASE-5196 URL: https://issues.apache.org/jira/browse/HBASE-5196 Project: HBase Issue Type: Bug Components: master, regionserver Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang If region split fails after PONR, it relies on the master ServerShutdown handler to fix it. However, if the master doesn't get a chance to fix it. There will be a hole in the region chain. -- 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-5150) Fail in a thread may not fail a test, clean up log splitting test
Fail in a thread may not fail a test, clean up log splitting test - Key: HBASE-5150 URL: https://issues.apache.org/jira/browse/HBASE-5150 Project: HBase Issue Type: Test Affects Versions: 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor This is to clean up some tests for HBASE-5081. The Assert.fail method in a separate thread will terminate the thread, but may not fail the test. We can use callable, so that we can get the error in getting the result. Some documentation to explain the test will be helpful 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] [Created] (HBASE-5112) TestReplication#queueFailover flaky due to code error
TestReplication#queueFailover flaky due to code error - Key: HBASE-5112 URL: https://issues.apache.org/jira/browse/HBASE-5112 Project: HBase Issue Type: Bug Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang In TestReplication#queueFailover, the second scan is not reset for each new scan. Followed scan may not be able to scan the whole table. So it cannot get all the data and the test fails. -- 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-5106) HBASE-3065 recoverable ZooKeeper, the new metadata introduced setData call breaks old hbase client.
HBASE-3065 recoverable ZooKeeper, the new metadata introduced setData call breaks old hbase client. --- Key: HBASE-5106 URL: https://issues.apache.org/jira/browse/HBASE-5106 Project: HBase Issue Type: Bug Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Old hbase client which talks to the new hbase server could not understand the new metadata. We should re-think how to check setData BADVERSION error. How about we check the full actual data? If the actual data in ZK is what we want to set, then we are good. Of course, this data could be set actually by someone else, in this case, is it safe not to throw a KeeperException? -- 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-5099) ZK event thread waiting for root region while server shutdown handler waiting for event thread to finish distributed log splitting to recover the region sever the root re
ZK event thread waiting for root region while server shutdown handler waiting for event thread to finish distributed log splitting to recover the region sever the root region is on Key: HBASE-5099 URL: https://issues.apache.org/jira/browse/HBASE-5099 Project: HBase Issue Type: Bug Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang A RS died. The ServerShutdownHandler kicked in and started the logspliting. SpliLogManager installed the tasks asynchronously, then started to wait for them to complete. The task znodes were not created actually. The requests were just queued. At this time, the zookeeper connection expired. HMaster tried to recover the expired ZK session. During the recovery, a new zookeeper connection was created. However, this master became the new master again. It tried to assign root and meta. Because the dead RS got the old root region, the master needs to wait for the log splitting to complete. This waiting holds the zookeeper event thread. So the async create split task is never retried since there is only one event thread, which is waiting for the root region assigned. -- 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-5081) Distributed log splitting deleteNode races againsth splitLog retry
Distributed log splitting deleteNode races againsth splitLog retry --- Key: HBASE-5081 URL: https://issues.apache.org/jira/browse/HBASE-5081 Project: HBase Issue Type: Bug Components: wal Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Recently, during 0.92 rc testing, we found distributed log splitting hangs there forever. Please see attached screen shot. I looked into it and here is what happened I think: 1. One rs died, the servershutdownhandler found it out and started the distributed log splitting; 2. All three tasks failed, so the three tasks were deleted, asynchronously; 3. Servershutdownhandler retried the log splitting; 4. During the retrial, it created these three tasks again, and put them in a hashmap (tasks); 5. The asynchronously deletion in step 2 finally happened for one task, in the callback, it removed one task in the hashmap; 6. One of the newly submitted tasks' zookeeper watcher found out that task is unassigned, and it is not in the hashmap, so it created a new orphan task. 7. All three tasks failed, but that task created in step 6 is an orphan so the batch.err counter was one short, so the log splitting hangs there and keeps waiting for the last task to finish which is never going to happen. So I think the problem is step 2. The fix is to make deletion sync, instead of async, so that the retry will have a clean start. Async deleteNode will mess up with split log retrial. In extreme situation, if async deleteNode doesn't happen soon enough, some node created during the retrial could be deleted. deleteNode should be sync. -- 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-5049) TestHLogSplit.testLogRollAfterSplitStart not working due to HBASE-5006
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 Priority: Trivial 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-4927) CatalogJanior:SplitParentFirstComparator doesn't sort as expected, for the last region when the endkey is empty
CatalogJanior:SplitParentFirstComparator doesn't sort as expected, for the last region when the endkey is empty --- Key: HBASE-4927 URL: https://issues.apache.org/jira/browse/HBASE-4927 Project: HBase Issue Type: Bug Components: master Affects Versions: 0.92.0, 0.94.0 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor When reviewing HBASE-4238 backporting, Jon found this issue. What happens if the split points are (empty end key is the last key, empty start key is the first key) Parent [A,) L daughter [A,B), R daughter [B,) When sorted, we gets to end key comparision which results in this incorrector order: [A,B), [A,), [B,) we wanted: [A,), [A,B), [B,) -- 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-4869) Backport to 0.92: HBASE-4797 [availability] Skip recovered.edits files with edits we know older than what region currently has.
Backport to 0.92: HBASE-4797 [availability] Skip recovered.edits files with edits we know older than what region currently has. --- Key: HBASE-4869 URL: https://issues.apache.org/jira/browse/HBASE-4869 Project: HBase Issue Type: Improvement Components: wal Affects Versions: 0.90.2 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Priority: Minor Fix For: 0.92.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] [Created] (HBASE-4820) Distributed log splitting coding enhancement to make it easier to understand, no semantics change
Distributed log splitting coding enhancement to make it easier to understand, no semantics change - Key: HBASE-4820 URL: https://issues.apache.org/jira/browse/HBASE-4820 Project: HBase Issue Type: Improvement Components: wal Affects Versions: 0.94.0 Reporter: Jimmy Xiang Priority: Minor Fix For: 0.94.0 In reviewing distributed log splitting feature, we found some cosmetic issues. They make the code hard to understand. It will be great to fix them. For this issue, there should be no semantic change. -- 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
