[jira] [Commented] (HBASE-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227015#comment-13227015 ] dhruba borthakur commented on HBASE-5560: - Lars is asking to change the default value to 5 min. Stack is asking the default value to 90 sec. any consensus? Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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-5128) [uber hbck] Enable hbck to automatically repair table integrity problems as well as region consistency problems while online.
[ https://issues.apache.org/jira/browse/HBASE-5128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227057#comment-13227057 ] jirapos...@reviews.apache.org commented on HBASE-5128: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4280/#review5826 --- src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java https://reviews.apache.org/r/4280/#comment12728 Precede regioninfo with a dot. src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java https://reviews.apache.org/r/4280/#comment12724 Looking at code @ line 2835 below, it seems -fixAssignments and -fix are equivalent. What was the reason for deprecating -fix ? src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java https://reviews.apache.org/r/4280/#comment12722 More than one option modifies .META. table. Shall we name this option fixMetaUsingRegionInfoOnHdfs ? src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java https://reviews.apache.org/r/4280/#comment12721 Can we name this option fixRegionHolesOnHdfs ? It would be better to note which options can be run with cluster offline. src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java https://reviews.apache.org/r/4280/#comment12723 Name this fixRegionOverlapsOnHdfs ? src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java https://reviews.apache.org/r/4280/#comment12725 white space. src/main/java/org/apache/hadoop/hbase/util/hbck/TableIntegrityErrorHandler.java https://reviews.apache.org/r/4280/#comment12726 Should read 'callbacks for handling particular table integrity invariant violations detected.' src/main/java/org/apache/hadoop/hbase/util/hbck/TableIntegrityErrorHandler.java https://reviews.apache.org/r/4280/#comment12730 Please add javadoc for the handleXXX methods on what scenario each fixes. src/main/java/org/apache/hadoop/hbase/util/hbck/TableIntegrityErrorHandler.java https://reviews.apache.org/r/4280/#comment12729 Since region always belongs to some table, I suggest naming this method handleNonEmptyRegionStartKey() src/main/java/org/apache/hadoop/hbase/util/hbck/TableIntegrityErrorHandler.java https://reviews.apache.org/r/4280/#comment12727 This class should be abstract. It is better to put it in its own file. - Ted On 2012-03-10 01:04:58, jmhsieh wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/4280/ bq. --- bq. bq. (Updated 2012-03-10 01:04:58) bq. bq. bq. Review request for hbase, Todd Lipcon, Ted Yu, and Lars Hofhansl. bq. bq. bq. Summary bq. --- bq. bq. This version is similar to the 0.90.x version posted a few months back, but has a few new features and some minor differences. bq. bq. 1) No trackHTD method needed since we can read from the file system. bq. 2) Added safeguards to prevent mega merges, and to isolate repairs to particular tables. bq. 3) Fixed comparator in HRegionInfo bq. 4) Fixed TestRegionObserverInterface so that it doesn't rely on bug in HRegionInfo comparator. bq. bq. I'll backport to 0.94/0.92 (which should be very similar) and update the 0.90 versions after this patch has mostly cleared. bq. bq. This version is not perfect (there are definitely cases not covered) but it think it is worth trying to get this in so that future reviews are more manageable. bq. bq. bq. This addresses bug HBASE-5128. bq. https://issues.apache.org/jira/browse/HBASE-5128 bq. bq. bq. Diffs bq. - bq. bq.src/main/java/org/apache/hadoop/hbase/HRegionInfo.java 98f79fc bq.src/main/java/org/apache/hadoop/hbase/ipc/HMasterInterface.java 3bcf899 bq.src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java ae468ca bq.src/main/java/org/apache/hadoop/hbase/master/HMaster.java e2bbbd0 bq.src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java 720841c bq.src/main/java/org/apache/hadoop/hbase/util/HBaseFsckRepair.java 5916d9c bq.src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java d57bb6b bq. src/main/java/org/apache/hadoop/hbase/util/hbck/TableIntegrityErrorHandler.java PRE-CREATION bq.src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java 38eb6a8 bq. src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverInterface.java 1b3b6df bq.src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java 937781d bq.src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckComparator.java 0599da1 bq.src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java dbb97f8 bq.
[jira] [Commented] (HBASE-5335) Dynamic Schema Configurations
[ https://issues.apache.org/jira/browse/HBASE-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227076#comment-13227076 ] Phabricator commented on HBASE-5335: nspiegelberg has commented on the revision [jira] [HBASE-5335] Dynamic Schema Config. INLINE COMMENTS src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:41 I think this would introduce a Guava dependency. I just wanted something with concise set notation for the rough draft. I'll try to use standard Java APIs for a future iteration since this is client-side. src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java:531 There is some special logic in HTD around ROOT META regions that make unification nontrivial. src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:452 thanks for the info. I'll remember to look into 92 implementation details of this when I do a trunk port. src/main/java/org/apache/hadoop/hbase/util/CompoundConfiguration.java:39 note that this is a private interface, so it wouldn't appear in javadoc. I should add some notes here though. src/main/ruby/hbase/admin.rb:177 you only hit this error if 1 was specified but the other wasn't. REVISION DETAIL https://reviews.facebook.net/D2247 Dynamic Schema Configurations - Key: HBASE-5335 URL: https://issues.apache.org/jira/browse/HBASE-5335 Project: HBase Issue Type: New Feature Reporter: Nicolas Spiegelberg Assignee: Nicolas Spiegelberg Labels: configuration, schema Attachments: D2247.1.patch Currently, the ability for a core developer to add per-table per-CF configuration settings is very heavyweight. You need to add a reserved keyword all the way up the stack you have to support this variable long-term if you're going to expose it explicitly to the user. This has ended up with using Configuration.get() a lot because it is lightweight and you can tweak settings while you're trying to understand system behavior [since there are many config params that may never need to be tuned]. We need to add the ability to put read arbitrary KV settings in the HBase schema. Combined with online schema change, this will allow us to safely iterate on configuration settings. -- 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-4890) fix possible NPE in HConnectionManager
[
https://issues.apache.org/jira/browse/HBASE-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227234#comment-13227234
]
stack commented on HBASE-4890:
--
IOE is better than NPE. The IOE says what the error is. What we want to do
about this scenario -- a process running serverside for longer than we're
prepared to wait -- is something we need to work on. We either add the
keep-alive or adjust the rpctimeout by the size of the request?
fix possible NPE in HConnectionManager
--
Key: HBASE-4890
URL: https://issues.apache.org/jira/browse/HBASE-4890
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.0
Reporter: Jonathan Hsieh
Assignee: stack
Priority: Blocker
Fix For: 0.92.1, 0.94.0
Attachments: 4890-v2.txt, 4890-v3.txt, 4890-v3.txt, 4890-v3.txt,
4890.txt, splits.txt
I was running YCSB against a 0.92 branch and encountered this error message:
{code}
11/11/29 08:47:16 WARN client.HConnectionManager$HConnectionImplementation:
Failed all from
region=usertable,user3917479014967760871,1322555655231.f78d161e5724495a9723bcd972f97f41.,
hostname=c0316.hal.cloudera.com, port=57020
java.util.concurrent.ExecutionException: java.lang.RuntimeException:
java.lang.NullPointerException
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatchCallback(HConnectionManager.java:1501)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatch(HConnectionManager.java:1353)
at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:898)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:775)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:750)
at com.yahoo.ycsb.db.HBaseClient.update(Unknown Source)
at com.yahoo.ycsb.DBWrapper.update(Unknown Source)
at com.yahoo.ycsb.workloads.CoreWorkload.doTransactionUpdate(Unknown
Source)
at com.yahoo.ycsb.workloads.CoreWorkload.doTransaction(Unknown Source)
at com.yahoo.ycsb.ClientThread.run(Unknown Source)
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithoutRetries(HConnectionManager.java:1315)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$3.call(HConnectionManager.java:1327)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$3.call(HConnectionManager.java:1325)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at
org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:158)
at $Proxy4.multi(Unknown Source)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$3$1.call(HConnectionManager.java:1330)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation$3$1.call(HConnectionManager.java:1328)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithoutRetries(HConnectionManager.java:1309)
... 7 more
{code}
It looks like the NPE is caused by server being null in the MultiRespone
call() method.
{code}
public MultiResponse call() throws IOException {
return getRegionServerWithoutRetries(
new ServerCallableMultiResponse(connection, tableName, null) {
public MultiResponse call() throws IOException {
return server.multi(multi);
}
@Override
public void connect(boolean reload) throws IOException {
server =
connection.getHRegionConnection(loc.getHostname(),
loc.getPort());
}
}
);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5128) [uber hbck] Enable hbck to automatically repair table integrity problems as well as region consistency problems while online.
[
https://issues.apache.org/jira/browse/HBASE-5128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227239#comment-13227239
]
Zhihong Yu commented on HBASE-5128:
---
bq. What was the reason for deprecating -fix ?
I guess -fixAll may take long time to execute now that hbck is able to fix
various types of problems.
Otherwise it may be desirable to let -fix correct all the problems.
[uber hbck] Enable hbck to automatically repair table integrity problems as
well as region consistency problems while online.
-
Key: HBASE-5128
URL: https://issues.apache.org/jira/browse/HBASE-5128
Project: HBase
Issue Type: New Feature
Components: hbck
Affects Versions: 0.90.5, 0.92.0, 0.94.0, 0.96.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
Attachments: hbase-5128-trunk.patch
The current (0.90.5, 0.92.0rc2) versions of hbck detects most of region
consistency and table integrity invariant violations. However with '-fix' it
can only automatically repair region consistency cases having to do with
deployment problems. This updated version should be able to handle all cases
(including a new orphan regiondir case). When complete will likely deprecate
the OfflineMetaRepair tool and subsume several open META-hole related issue.
Here's the approach (from the comment of at the top of the new version of the
file).
{code}
/**
* HBaseFsck (hbck) is a tool for checking and repairing region consistency
and
* table integrity.
*
* Region consistency checks verify that META, region deployment on
* region servers and the state of data in HDFS (.regioninfo files) all are in
* accordance.
*
* Table integrity checks verify that that all possible row keys can resolve
to
* exactly one region of a table. This means there are no individual
degenerate
* or backwards regions; no holes between regions; and that there no
overlapping
* regions.
*
* The general repair strategy works in these steps.
* 1) Repair Table Integrity on HDFS. (merge or fabricate regions)
* 2) Repair Region Consistency with META and assignments
*
* For table integrity repairs, the tables their region directories are
scanned
* for .regioninfo files. Each table's integrity is then verified. If there
* are any orphan regions (regions with no .regioninfo files), or holes, new
* regions are fabricated. Backwards regions are sidelined as well as empty
* degenerate (endkey==startkey) regions. If there are any overlapping
regions,
* a new region is created and all data is merged into the new region.
*
* Table integrity repairs deal solely with HDFS and can be done offline --
the
* hbase region servers or master do not need to be running. These phase can
be
* use to completely reconstruct the META table in an offline fashion.
*
* Region consistency requires three conditions -- 1) valid .regioninfo file
* present in an hdfs region dir, 2) valid row with .regioninfo data in META,
* and 3) a region is deployed only at the regionserver that is was assigned
to.
*
* Region consistency requires hbck to contact the HBase master and region
* servers, so the connect() must first be called successfully. Much of the
* region consistency information is transient and less risky to repair.
*/
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-2039) G1 GC issues
[ https://issues.apache.org/jira/browse/HBASE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227254#comment-13227254 ] stack commented on HBASE-2039: -- A post by Jonathan Payne on G1 not working for him: http://printfdebugger.tumblr.com/post/19142660766/how-i-learned-to-love-cms-and-had-my-heart-broken-by-g1 G1 GC issues Key: HBASE-2039 URL: https://issues.apache.org/jira/browse/HBASE-2039 Project: HBase Issue Type: Bug Reporter: stack Lets keep an issue where we report on g1 issues. Lets keep list of crashes we see. I filed an issue up on bug parade. Lets see if it becomes actual bug. Below I note version of vm and the type of crash (Internal Error (nmethod.cpp:1981), pid=32319. Its a 'fatal error'). It happens for me after 5-10 minutes when a loading test. Same thing each time. G1 in 1.6 seems plain broke; crashes on use of stuff in concurrent utils package. Date Created: Thu Dec 10 13:33:04 MST 2009 .. Synopsis:Running G1 GC, crashes with Internal Error (nmethod.cpp:1981), pid=32319... Description: FULL PRODUCT VERSION : java version 1.7.0-ea Java(TM) SE Runtime Environment (build 1.7.0-ea-b77) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b05, mixed mode) FULL OS VERSION : Fedora Core release 6 (Zod) EXTRA RELEVANT SYSTEM CONFIGURATION : Here are the JVM args: -XX:+HeapDumpOnOutOfMemoryError -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -- 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-2039) G1 GC issues
[ https://issues.apache.org/jira/browse/HBASE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227253#comment-13227253 ] stack commented on HBASE-2039: -- A post by Jonathan Payne on G1 not working for him: http://printfdebugger.tumblr.com/post/19142660766/how-i-learned-to-love-cms-and-had-my-heart-broken-by-g1 G1 GC issues Key: HBASE-2039 URL: https://issues.apache.org/jira/browse/HBASE-2039 Project: HBase Issue Type: Bug Reporter: stack Lets keep an issue where we report on g1 issues. Lets keep list of crashes we see. I filed an issue up on bug parade. Lets see if it becomes actual bug. Below I note version of vm and the type of crash (Internal Error (nmethod.cpp:1981), pid=32319. Its a 'fatal error'). It happens for me after 5-10 minutes when a loading test. Same thing each time. G1 in 1.6 seems plain broke; crashes on use of stuff in concurrent utils package. Date Created: Thu Dec 10 13:33:04 MST 2009 .. Synopsis:Running G1 GC, crashes with Internal Error (nmethod.cpp:1981), pid=32319... Description: FULL PRODUCT VERSION : java version 1.7.0-ea Java(TM) SE Runtime Environment (build 1.7.0-ea-b77) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b05, mixed mode) FULL OS VERSION : Fedora Core release 6 (Zod) EXTRA RELEVANT SYSTEM CONFIGURATION : Here are the JVM args: -XX:+HeapDumpOnOutOfMemoryError -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -- 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-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227297#comment-13227297 ] Lars Hofhansl commented on HBASE-5560: -- easiest is to just leave the 15m default Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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-5548) Add ability to get a table in the shell
[
https://issues.apache.org/jira/browse/HBASE-5548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Yates updated HBASE-5548:
---
Attachment: ruby_HBASE-5548-v1.patch
Attaching patch...
1) Fixed stack's comments
2) Added features:
- create now returns the table that was created
- scan now dynamically adds a scan method to htable
The latter makes sure that the table will output a scan 'nicely', and could be
a decent paradigm for adding methods to the Table class (though probably some
cleanup needs to be done as far as aliasing methods etc.). Thoughts on this new
style?
Also, here is the output from some usage:
{code}
1.9.2-p290 :006 t = create 't', 'f'
0 row(s) in 1.0470 seconds
= #Hbase::Table:0x55187eb3
@table=#Java::OrgApacheHadoopHbaseClient::HTable:0x92524b0,
@shell=#Shell::Shell:0x329b5c95
@formatter=#Shell::Formatter::Console:0x75db5427 @out=Kernel, @row_count=0,
@max_width=80, @hbase_admin=#Hbase::Admin:0x127208e4
@zk_wrapper=#Java::OrgApacheHadoopHbaseZookeeper::ZooKeeperWatcher:0xcb80017,
@zk_main=#Java::OrgApacheZookeeper::ZooKeeperMain:0x646326e5,
@formatter=#Shell::Formatter::Console:0x75db5427 @out=Kernel, @row_count=0,
@max_width=80, @conf=#Java::OrgApacheHadoopConf::Configuration:0x4332b67c,
@admin=#Java::OrgApacheHadoopHbaseClient::HBaseAdmin:0x2fbb3e9a,
@hbase=#Hbase::Hbase:0x56781dd4
@configuration=#Java::OrgApacheHadoopConf::Configuration:0x4332b67c
1.9.2-p290 :007 t.put 'r', 'f', 'v'
1.9.2-p290 :008 t1 = get_table 't'
0 row(s) in 0.0240 seconds
= #Hbase::Table:0x7194f467
@table=#Java::OrgApacheHadoopHbaseClient::HTable:0x6a39d072,
@shell=#Shell::Shell:0x329b5c95
@formatter=#Shell::Formatter::Console:0x75db5427 @out=Kernel, @row_count=0,
@max_width=80, @hbase_admin=#Hbase::Admin:0x127208e4
@zk_wrapper=#Java::OrgApacheHadoopHbaseZookeeper::ZooKeeperWatcher:0xcb80017,
@zk_main=#Java::OrgApacheZookeeper::ZooKeeperMain:0x646326e5,
@formatter=#Shell::Formatter::Console:0x75db5427 @out=Kernel, @row_count=0,
@max_width=80, @conf=#Java::OrgApacheHadoopConf::Configuration:0x4332b67c,
@admin=#Java::OrgApacheHadoopHbaseClient::HBaseAdmin:0x2fbb3e9a,
@hbase=#Hbase::Hbase:0x56781dd4
@configuration=#Java::OrgApacheHadoopConf::Configuration:0x4332b67c
1.9.2-p290 :009 t.put 'r2', 'f', 'v'
1.9.2-p290 :010 t.scan
ROW COLUMN+CELL
rcolumn=f:, timestamp=1331521351836, value=v
r2 column=f:, timestamp=1331521368969, value=v
2 row(s) in 0.0870 seconds
{code}
Add ability to get a table in the shell
---
Key: HBASE-5548
URL: https://issues.apache.org/jira/browse/HBASE-5548
Project: HBase
Issue Type: Improvement
Components: shell
Reporter: Jesse Yates
Assignee: Jesse Yates
Fix For: 0.96.0
Attachments: ruby_HBASE-5528-v0.patch, ruby_HBASE-5548-v1.patch
Currently, all the commands that operate on a table in the shell first have
to take the table as name as input.
There are two main considerations:
* It is annoying to have to write the table name every time, when you should
just be able to get a reference to a table
* the current implementation is very wasteful - it creates a new HTable for
each call (but reuses the connection since it uses the same configuration)
We should be able to get a handle to a single HTable and then operate on that.
--
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-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227311#comment-13227311 ] dhruba borthakur commented on HBASE-5560: - The problem with the 5 min default is that it gives a bad-user experience out-of-the-box. If people are ok with it, I would prefer to change it to 90 seconds as Stack proposed. Is that ok with you lars? I know it breaks backward compatibility, but I will update the release-notes in the JIRA Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227319#comment-13227319 ] stack commented on HBASE-5560: -- Pardon me lads. Did not mean to confuse. Lars I was telling a story. It used to be a queue of 100 times the number of handlers. After we figured that, it was changed to be configurable and ten by default. On 15 minutes, that seems way too long. I'm good w/ 5 minutes but would prefer 90 seconds (which is 1.5 times the rpcTimeout -- the client won't be there after 60 seconds pass... should we hold on for some factor times rpcTimeout?). Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227322#comment-13227322 ] Lars Hofhansl commented on HBASE-5560: -- Heh... +1 on 90s timeout. Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227323#comment-13227323 ] dhruba borthakur commented on HBASE-5560: - The default rpc client timeout is Max_Value, see HConstants.DEFAULT_HBASE_CLIENT_OPERATION_TIMEOUT. where do you see that rpcTimeout is ti be 60 seconds? Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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-5563) HRegionInfo#compareTo add the comparison of regionId
HRegionInfo#compareTo add the comparison of regionId Key: HBASE-5563 URL: https://issues.apache.org/jira/browse/HBASE-5563 Project: HBase Issue Type: Bug Reporter: chunhui shen Assignee: chunhui shen In the one region multi assigned case, we could find that two regions have the same table name, same startKey, same endKey, and different regionId, so these two regions are same in TreeMap but different in HashMap. -- 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-5563) HRegionInfo#compareTo add the comparison of regionId
[ https://issues.apache.org/jira/browse/HBASE-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunhui shen updated HBASE-5563: Attachment: HBASE-5563.patch HRegionInfo#compareTo add the comparison of regionId Key: HBASE-5563 URL: https://issues.apache.org/jira/browse/HBASE-5563 Project: HBase Issue Type: Bug Reporter: chunhui shen Assignee: chunhui shen Attachments: HBASE-5563.patch In the one region multi assigned case, we could find that two regions have the same table name, same startKey, same endKey, and different regionId, so these two regions are same in TreeMap but different in HashMap. -- 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-5560) Avoid RegionServer GC caused by timed-out calls
[ https://issues.apache.org/jira/browse/HBASE-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phabricator updated HBASE-5560: --- Attachment: D2241.3.patch dhruba updated the revision [jira][HBASE-5560] Avoid RegionServer GC caused by timed-out calls. Reviewers: stack, tedyu, sc, JIRA Changed default purge-timeout to 90 seconds REVISION DETAIL https://reviews.facebook.net/D2241 AFFECTED FILES src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java Avoid RegionServer GC caused by timed-out calls --- Key: HBASE-5560 URL: https://issues.apache.org/jira/browse/HBASE-5560 Project: HBase Issue Type: Improvement Reporter: dhruba borthakur Assignee: dhruba borthakur Fix For: 0.94.0, 0.96.0 Attachments: D2241.1.patch, D2241.2.patch, D2241.3.patch The HBaseRpcServer queues up rpc responses if the socket connection to the client is not yet ready to receive data. Calls are queued here until a 15 minute timeout occurs. I am able to generate a full GC when I artificially make a client read rpc-responses very slowly. This jira is to make this 15 minute time configurable. -- 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
