[jira] [Created] (HBASE-5438) A tool to check region balancing for a particular table
A tool to check region balancing for a particular table --- Key: HBASE-5438 URL: https://issues.apache.org/jira/browse/HBASE-5438 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang When debugging the table level region imbalance problem, I write a tool to check how the region balanced across all the region server for a particular table. bin/hbase org.jruby.Main region_balance_checker.rb test_table -- 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-5474) Shared the multiput thread pool for all the HTable instance
Shared the multiput thread pool for all the HTable instance --- Key: HBASE-5474 URL: https://issues.apache.org/jira/browse/HBASE-5474 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Currently, each HTable instance will have a thread pool for the multiput operation. Each thread pool is actually a unbounded cached thread pool. So it would increase the efficiency if HTable could share this unbounded cached thread pool across all the HTable instance ? -- 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-5535) Make the functions in task monitor synchronized
Make the functions in task monitor synchronized --- Key: HBASE-5535 URL: https://issues.apache.org/jira/browse/HBASE-5535 Project: HBase Issue Type: Bug Reporter: Liyin Tang Assignee: Liyin Tang There are some potential race condition in the task monitor. So update the functions in task monitor to be synchronized. The example of the problem caused by the race condition: ERROR org.apache.hadoop.hbase.regionserver.MemStoreFlusher: Cache flush failed for region java.lang.IndexOutOfBoundsException: Index: 1745, Size: 1744 at java.util.ArrayList.add(ArrayList.java:367) at java.util.SubList.add(AbstractList.java:633) at java.util.SubList.add(AbstractList.java:633) at java.util.SubList.add(AbstractList.java:633) at java.util.SubList.add(AbstractList.java:633) at java.util.SubList.add(AbstractList.java:633) at java.util.AbstractList.add(AbstractList.java:91) at org.apache.hadoop.hbase.monitoring.TaskMonitor.createStatus(TaskMonitor.java:74) at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:1139) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:260) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:234) at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.run(MemStoreFlusher.java:146) -- 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-5199) Delete out of TTL store files before compaction selection
Delete out of TTL store files before compaction selection - Key: HBASE-5199 URL: https://issues.apache.org/jira/browse/HBASE-5199 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Currently, HBase deletes the out of TTL store files after major compaction. We can change the sequence to delete the out of TTL store files before selecting store files for compactions. In this way, HBase can keep deleting the old invalid store files without major compaction, and also prevent from unnecessary major compactions since the out of TTL store files will be deleted before the compaction selection. -- 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-5259) Normalize the RegionLocation in TableInputFormat by the reverse DNS lookup.
Normalize the RegionLocation in TableInputFormat by the reverse DNS lookup. --- Key: HBASE-5259 URL: https://issues.apache.org/jira/browse/HBASE-5259 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Assuming the HBase and MapReduce running in the same cluster, the TableInputFormat is to override the split function which divides all the regions from one particular table into a series of mapper tasks. So each mapper task can process a region or one part of a region. Ideally, the mapper task should run on the same machine on which the region server hosts the corresponding region. That's the motivation that the TableInputFormat sets the RegionLocation so that the MapReduce framework can respect the node locality. The code simply set the host name of the region server as the HRegionLocation. However, the host name of the region server may have different format with the host name of the task tracker (Mapper task). The task tracker always gets its hostname by the reverse DNS lookup. And the DNS service may return different host name format. For example, the host name of the region server is correctly set as a.b.c.d while the reverse DNS lookup may return a.b.c.d. (With an additional doc in the end). So the solution is to set the RegionLocation by the reverse DNS lookup as well. No matter what host name format the DNS system is using, the TableInputFormat has the responsibility to keep the consistent host name format with the MapReduce framework. -- 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-5274) Filter out the expired store file scanner during the compaction
Filter out the expired store file scanner during the compaction --- Key: HBASE-5274 URL: https://issues.apache.org/jira/browse/HBASE-5274 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang During the compaction time, HBase will generate a store scanner which will scan a list of store files. And it would be more efficient to filer out the expired store file since there is no need to read any key values from these store files. This optimization has been already implemented on 89-fb and this is the building block for HBASE-5199 as well. It is supposed to be no-ops to compact the expired store 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-5290) [FindBugs] Synchronization on boxed primitive
[FindBugs] Synchronization on boxed primitive
-
Key: HBASE-5290
URL: https://issues.apache.org/jira/browse/HBASE-5290
Project: HBase
Issue Type: Bug
Reporter: Liyin Tang
Assignee: Liyin Tang
Priority: Minor
This bug is reported by the findBugs tool, which is a static analysis tool.
Bug: Synchronization on Integer in
org.apache.hadoop.hbase.regionserver.compactions.CompactSelection.emptyFileList()
The code synchronizes on a boxed primitive constant, such as an Integer.
private static Integer count = 0;
...
synchronized(count) {
count++;
}
...
Since Integer objects can be cached and shared, this code could be
synchronizing on the same object as other, unrelated code, leading to
unresponsiveness and possible deadlock
See CERT CON08-J. Do not synchronize on objects that may be reused for more
information.
Confidence: Normal, Rank: Troubling (14)
Pattern: DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE
Type: DL, Category: MT_CORRECTNESS (Multithreaded correctness)
--
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-5315) Asynchronously table creation shall verify all the regions online
Asynchronously table creation shall verify all the regions online - Key: HBASE-5315 URL: https://issues.apache.org/jira/browse/HBASE-5315 Project: HBase Issue Type: Improvement Reporter: Liyin Tang HBaseAdmin creates table in an asynchronous way and it needs to verify all the regions online. -- 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-5316) Separate the client configuration for HTable and HBaseAdmin
Separate the client configuration for HTable and HBaseAdmin --- Key: HBASE-5316 URL: https://issues.apache.org/jira/browse/HBASE-5316 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Currently HTable and HBaseAdmin read configurations based on the same config key, such as hbase.client.retries.number and hbase.client.retries.number Actually in some cases, the client needs different settings for HTable operations and HBaseAdmin operations. One way is to pass different HBaseConfiguration objects to HTable and HBaseAdmin. Another much clearer way is to separate the configurations for HTable and HBaseAdmin by using different config keys. -- 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-5369) Compaction selection based on the hotness of the HFile's block in the block cache
Compaction selection based on the hotness of the HFile's block in the block cache - Key: HBASE-5369 URL: https://issues.apache.org/jira/browse/HBASE-5369 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang HBase reserves a large set memory for the block cache and the cached blocks will be age out in a LRU fashion. Obviously, we don't want to age out the blocks which are still hot. However, when the compactions are starting, these hot blocks may naturally be invalid. Considering that the block cache has already known which HFiles these hot blocks come from, the compaction selection algorithm could just simply skip compact these HFiles until these block cache become cold. Furthermore, the HBase could compact multiple HFiles into two HFiles. One of them only contains hot blocks which are supposed be cached directly. -- 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-5373) Table level lock to prevent the race of multiple table level operation
Table level lock to prevent the race of multiple table level operation -- Key: HBASE-5373 URL: https://issues.apache.org/jira/browse/HBASE-5373 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang A table level lock can guarantee that only one table operation would happen at one time for each table. The master should require and release these table locks correctly during the failover time. One proposal is to keep track of the lock and its corresponding operation in the zookeeper. If there is a master failover, the secondary should have a way to check whether these operations are succeeded nor not before releasing the 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-5381) Make memstore.flush.size as a table level configuration
Make memstore.flush.size as a table level configuration --- Key: HBASE-5381 URL: https://issues.apache.org/jira/browse/HBASE-5381 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Currently the region server will flush mem store of the region based on the limitation of the global mem store flush size and global low water mark. However, It will cause the hot tables, which serve more write traffic, to flush too frequently even though the overall mem store heap usage is quite low. Too frequently flush would also contribute to too many minor compactions. So if we can make memstore.flush.size as a table level configuration, it would be more flexible to config different tables with different desired mem store flush size based on compaction ratio, recovery time and put ops. -- 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-5383) Prevent the compaction read requests from changing the hotness of block cache
Prevent the compaction read requests from changing the hotness of block cache - Key: HBASE-5383 URL: https://issues.apache.org/jira/browse/HBASE-5383 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Block cache is organized in an sorted way based on LRU or some other algorithm and it will age out some blocks when the algorithm believes these blocks are not hot any more. The motivation here is to prevent the compaction read requests from changing the hotness of block cache. -- 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-5403) Checkpoint the compressed HLog
Checkpoint the compressed HLog -- Key: HBASE-5403 URL: https://issues.apache.org/jira/browse/HBASE-5403 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Let's assume that HBase replication can be based on replaying the HLog in the replica cluster. The replica process could be crash during the replay. Obviously, the replica process need a way to start from the lastest check point in the HLog, even the HLog is compressed. So the proposal is to write a series of checkpoints within the HLog. Each each checkpoint will have a header with some special sequence of bytes. And between each checkpoints, HLog should use new dictionaries to compress. -- 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-5407) Show the per-region level request count in the web ui
Show the per-region level request count in the web ui - Key: HBASE-5407 URL: https://issues.apache.org/jira/browse/HBASE-5407 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang It would be nice to show the per-region level request count in the web ui, especially when debugging the hot region problem. -- 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-5776) HTableMultiplexer
HTableMultiplexer -- Key: HBASE-5776 URL: https://issues.apache.org/jira/browse/HBASE-5776 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang There is a known issue in HBase client that single slow/dead region server could slow down the multiput operations across all the region servers. So the HBase client will be as slow as the slowest region server in the cluster. To solve this problem, HTableMultiplexer will separate the multiput submitting threads with the flush threads, which means the multiput operation will be a nonblocking operation. The submitting thread will shard all the puts into different queues based on its destination region server and return immediately. The flush threads will flush these puts from each queue to its destination region server. Currently the HTableMultiplexer only supports the put operation. -- 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-5799) [89-fb] Multiget API may return incomplete resutls
[89-fb] Multiget API may return incomplete resutls -- Key: HBASE-5799 URL: https://issues.apache.org/jira/browse/HBASE-5799 Project: HBase Issue Type: Bug Reporter: Liyin Tang There is a serious bug in the multiget which will cause the multiget function only returns part of the results. In the process function: The initial region is set before sorting the input list. So after the input list has been sorted, the initial region may no longer be the correct region for the first row in the sorted list. So the first row in the sorted list may be sent to the wrong region server which has no result for this row. -- 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-4491) HBase Locality Checker
HBase Locality Checker -- Key: HBASE-4491 URL: https://issues.apache.org/jira/browse/HBASE-4491 Project: HBase Issue Type: New Feature Reporter: Liyin Tang Assignee: Liyin Tang If we run data node and region server in the same physical machine, region server will be benefit if the store files for its serving regions have a local replica in the data node process. So for each regions, there exists a best locality region server which has most local blocks for this region. The HBase Locality Checker will show how many regions is running on its best locality region server. The higher the number is, the more performance benefits HBase can get from data locality. Also there would be a followup task to use these region locality information for region assignment. Assignment manager will prefer assign regions to its best locality region 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] [Created] (HBASE-4525) HBase always run with default hadoop setting.
HBase always run with default hadoop setting. - Key: HBASE-4525 URL: https://issues.apache.org/jira/browse/HBASE-4525 Project: HBase Issue Type: Bug Reporter: Liyin Tang When we build the hbase, we can say which version of hadoop we want to build with. For example: mvn -DskipTests=true package mvn -Dhadoop.profile=22 -DskipTests=true package However during the runtime, bin/hbase scripts will call add_maven_deps_to_classpath, which will always add the default hadoop version(0.20-append) to classpath (targets/cached_classpath.txt). -- 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-4532) Avoid top row seek by dedicated bloom filter for delete family
Avoid top row seek by dedicated bloom filter for delete family -- Key: HBASE-4532 URL: https://issues.apache.org/jira/browse/HBASE-4532 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang HBASE-4469 avoids 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. -- 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-4568) Make zk dump jsp response more quickly
Make zk dump jsp response more quickly -- Key: HBASE-4568 URL: https://issues.apache.org/jira/browse/HBASE-4568 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang For each zk dump, currently hbase will create a zk client instance every time. This is quite slow when any machines in the quorum is dead. Because it will connect to each machine in the zk quorum again. HMaster master = (HMaster)getServletContext().getAttribute(HMaster.MASTER); Configuration conf = master.getConfiguration(); HBaseAdmin hbadmin = new HBaseAdmin(conf); HConnection connection = hbadmin.getConnection(); ZooKeeperWatcher watcher = connection.getZooKeeperWatcher(); So we can simplify this: HMaster master = (HMaster)getServletContext().getAttribute(HMaster.MASTER); ZooKeeperWatcher watcher = master.getZooKeeperWatcher(); Also when hbase call getServerStats() for each machine in the zk quorum, it hard coded the default time out as 1 min. It would be nice to make this configurable and set it to a low time out. -- 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-4585) Avoid seek operation when current kv is deleted
Avoid seek operation when current kv is deleted --- Key: HBASE-4585 URL: https://issues.apache.org/jira/browse/HBASE-4585 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang When the current kv is deleted during the matching in the ScanQueryMatcher, currently the matcher will return skip and continue to seek. Actually, if the current kv is deleted because of family deleted or column deleted, the matcher should seek to next col. If the current kv is deleted because of version deleted, the matcher should just return skip. -- 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-4592) Get HFile request count based on the block type
Get HFile request count based on the block type --- Key: HBASE-4592 URL: https://issues.apache.org/jira/browse/HBASE-4592 Project: HBase Issue Type: New Feature Reporter: Liyin Tang Assignee: Liyin Tang Currently, the CacheStats can only get the total request count for all the block type. We can break down this metrics to different block type. It will benefit us to get more fine grained metrics. -- 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-4689) [89-fb] Fix table level rpc* metrics
[89-fb] Fix table level rpc* metrics Key: HBASE-4689 URL: https://issues.apache.org/jira/browse/HBASE-4689 Project: HBase Issue Type: Sub-task Affects Versions: 0.89.20100924 Reporter: Liyin Tang Assignee: Liyin Tang In r1182034, the per table/cf for rpc* metrics has a bug. It will only show cf level metrics even though we enabled the per table level metrics. Fix this bug here. -- 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-4698) Let the HFile Pretty Printer print all the key values for a specific row.
Let the HFile Pretty Printer print all the key values for a specific row. - Key: HBASE-4698 URL: https://issues.apache.org/jira/browse/HBASE-4698 Project: HBase Issue Type: New Feature Reporter: Liyin Tang Assignee: Liyin Tang When using HFile Pretty Printer to debug HBase issues, it would very nice to allow the Pretty Printer to seek to a specific row, and only print all the key values for this row. -- 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-4742) Split dead server's log in parallel
Split dead server's log in parallel --- Key: HBASE-4742 URL: https://issues.apache.org/jira/browse/HBASE-4742 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang When one region server goes down, the master will shutdown the region server and split its log. However, splitting log is a blocking call and it would take some time. If more than one region server go down, the master will split its log one by one, which is not efficient. Since we have the distributed log split, we could split these logs from the dead servers in parallel. -- 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-5032) Add DELETE COLUMN into the delete bloom filter
Add DELETE COLUMN into the delete bloom filter -- Key: HBASE-5032 URL: https://issues.apache.org/jira/browse/HBASE-5032 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Previously, the delete family bloom filter only contains the row key which has the delete family. It helps us to avoid the top-row seek operation. This jira attempts to add the delete column into this delete bloom filter as well (rename the delete family bloom filter as delete bloom filter). The motivation is to save seek ops for scan time-range queries if we know there is no delete column for this row/column. We can seek directly to the exact timestamp we are interested in, instead of seeking to the latest timestamp and keeping skipping to found out whether there is any delete column before the interested timestamp. -- 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-5033) Opening store files in parallel to reduce region open time
Opening store files in parallel to reduce region open time -- Key: HBASE-5033 URL: https://issues.apache.org/jira/browse/HBASE-5033 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang Opening store files in parallel to reduce region open time -- 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-5045) Add the table name and cf name for the next call int the task monitor
Add the table name and cf name for the next call int the task monitor - Key: HBASE-5045 URL: https://issues.apache.org/jira/browse/HBASE-5045 Project: HBase Issue Type: Improvement Reporter: Liyin Tang Assignee: Liyin Tang In the task monitor, we don't have much information about the next call compared to other operations. It would be nice to add the table name and cf name for each next call in the task monitor. -- 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
