[jira] [Reopened] (HBASE-5190) Limit the IPC queue size based on calls' payload size

2012-03-25 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-5190:
---


The new parameter to Call ctor causes secure HBase build to fail.

 Limit the IPC queue size based on calls' payload size
 -

 Key: HBASE-5190
 URL: https://issues.apache.org/jira/browse/HBASE-5190
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.90.5
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
 Fix For: 0.94.0, 0.96.0

 Attachments: HBASE-5190-v2.patch, HBASE-5190-v3.patch, 
 HBASE-5190.patch


 Currently we limit the number of calls in the IPC queue only on their count. 
 It used to be really high and was dropped down recently to num_handlers * 10 
 (so 100 by default) because it was easy to OOME yourself when huge calls were 
 being queued. It's still possible to hit this problem if you use really big 
 values and/or a lot of handlers, so the idea is that we should take into 
 account the payload size. I can see 3 solutions:
  - Do the accounting outside of the queue itself for all calls coming in and 
 out and when a call doesn't fit, throw a retryable exception.
  - Same accounting but instead block the call when it comes in until space is 
 made available.
  - Add a new parameter for the maximum size (in bytes) of a Call and then set 
 the size the IPC queue (in terms of the number of items) so that it could 
 only contain as many items as some predefined maximum size (in bytes) for the 
 whole queue.

--
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] [Reopened] (HBASE-5592) Make it easier to get a table from shell

2012-03-17 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-5592:
---


Jesse and I object to this going into 0.92

 Make it easier to get a table from shell
 

 Key: HBASE-5592
 URL: https://issues.apache.org/jira/browse/HBASE-5592
 Project: HBase
  Issue Type: Improvement
  Components: shell
Affects Versions: 0.94.0
Reporter: Ben West
Assignee: Ben West
Priority: Trivial
  Labels: shell
 Fix For: 0.92.2, 0.94.0

 Attachments: publicTable.patch


 The one argument constructor to HTable was removed at some point, which means 
 that you now have to pass in a Configuration to instantiate an HTable. This 
 is annoying for me when I create quick scripts.
 This JIRA is a tiny patch which lets you get an HTable instance in the shell 
 by doing
 {code}foo_table = @shell.hbase_table('foo').table{code}
 Basically, it is changing table to be a public member rather than a private 
 one.

--
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] [Reopened] (HBASE-4927) CatalogJanior:SplitParentFirstComparator doesn't sort as expected, for the last region when the endkey is empty

2011-12-07 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-4927:
---


As we can see from the report here:
https://issues.apache.org/jira/browse/HBASE-4927?focusedCommentId=13163785page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13163785

there were 3 failed tests.
These test failures rippled through all 0.92 builds.

 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
 Fix For: 0.92.0

 Attachments: 
 0001-HBASE-4927-CatalogJanior-SplitParentFirstComparator-.patch, 
 0001-HBASE-4927-CatalogJanior-SplitParentFirstComparator_v2.patch, 
 hbase-4927-fix-ws.txt


 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] [Reopened] (HBASE-4856) Upgrade zookeeper to 3.4.0 release

2011-11-23 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-4856:
---


Wasn't able to pull 3.4.0 artifact from maven repository.

 Upgrade zookeeper to 3.4.0 release
 --

 Key: HBASE-4856
 URL: https://issues.apache.org/jira/browse/HBASE-4856
 Project: HBase
  Issue Type: Task
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.92.0

 Attachments: 4856.txt


 Zookeeper 3.4.0 has been released.
 We should upgade.

--
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] [Reopened] (HBASE-4768) Per-(table, columnFamily) metrics with configurable table name inclusion

2011-11-15 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-4768:
---


TestHFileBlock fails on Jenkins.

 Per-(table, columnFamily) metrics with configurable table name inclusion
 

 Key: HBASE-4768
 URL: https://issues.apache.org/jira/browse/HBASE-4768
 Project: HBase
  Issue Type: New Feature
Reporter: Mikhail Bautin
Assignee: Mikhail Bautin
 Fix For: 0.94.0

 Attachments: D363.1.patch, D363.2.patch, D363.3.patch, D363.4.patch, 
 D363.5.patch


 As we kept adding more granular block read and block cache usage statistics, 
 a combinatorial explosion of various cases to monitor started to happen, 
 especially when we wanted both per-table/column family/block type statistics 
 and aggregate statistics on various subsets of these dimensions. Here, we 
 un-clutters HFile readers, LruBlockCache, StoreFile, etc. by creating a 
 centralized class that knows how to update all kinds of per-table/CF/block 
 type counters. 
 Table name and column family configuration have been pushed to a base class, 
 SchemaConfigured. This is convenient as many of existing classes that have 
 these properties (HFile readers/writers, HFile blocks, etc.) did not have a 
 base class. Whether to collect per-(table, columnFamily) or per-columnFamily 
 only metrics can be configured with the hbase.metrics.showTableName 
 configuration key. We don't expect this configuration to change at runtime, 
 so we cache the setting statically and log a warning when an attempt is made 
 to flip it once already set. This way we don't have to pass configuration to 
 a lot more places, e.g. everywhere an HFile reader is instantiated.
 Thanks to Liyin for his initial version of per-table metrics patch and a lot 
 of valuable feedback.

--
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] [Reopened] (HBASE-4552) multi-CF bulk load is not atomic across column families

2011-10-29 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-4552:
---


 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

 Attachments: hbase-4552.consolidated.patch, 
 hbase-4552.consolidated.v2.patch


 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] [Reopened] (HBASE-4694) Some cleanup of log messages in RS and M

2011-10-28 Thread Ted Yu (Reopened) (JIRA)

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

Ted Yu reopened HBASE-4694:
---


At least the following change to DefaultLoadBalancer.java shouldn't have been 
made:
{code}
-  numRegions += sz;
-  serversByLoad.put(new ServerAndLoad(server.getKey(), sz), regions);
{code}
The two load balancer related tests failed due to above change.

 Some cleanup of log messages in RS and M
 

 Key: HBASE-4694
 URL: https://issues.apache.org/jira/browse/HBASE-4694
 Project: HBase
  Issue Type: Improvement
Reporter: stack
Assignee: stack
 Fix For: 0.92.0

 Attachments: logging.txt


 I did a little edit of logging.  We do way too much but am not going to do a 
 big overhaul just yet.  Here's a few small changes saving a few lines, some 
 redundancy, and making others look like surrounding log lines.

--
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