[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Assignee: Lars Hofhansl New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.94.6, 0.95.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Fix For: 0.95.2 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Fix Version/s: 0.94.11 0.98.0 New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.94.6, 0.95.0 Reporter: Lars Hofhansl Assignee: Lars Hofhansl Priority: Minor Fix For: 0.98.0, 0.95.2, 0.94.11 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6580: - Fix Version/s: (was: 0.95.1) 0.95.2 New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.94.6, 0.95.0 Reporter: Lars Hofhansl Priority: Minor Fix For: 0.95.2 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6580: - Status: Open (was: Patch Available) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.95.0, 0.94.6 Reporter: Lars Hofhansl Priority: Minor Fix For: 0.95.1 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Fix Version/s: (was: 0.94.6) 0.94.7 New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.95.0, 0.94.6 Reporter: Lars Hofhansl Priority: Minor Fix For: 0.95.0, 0.94.7 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Fix Version/s: (was: 0.94.5) 0.94.6 New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.2 Reporter: Lars Hofhansl Priority: Minor Fix For: 0.96.0, 0.94.6 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Fix Version/s: 0.94.5 0.96.0 New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.2 Reporter: Lars Hofhansl Priority: Minor Fix For: 0.96.0, 0.94.5 Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-6580: - Attachment: HBASE_v2.patch Added HConnection#getTable() New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.2 Reporter: Lars Hofhansl Priority: Minor Attachments: HBASE-6580_v1.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-6580: - Attachment: (was: HBASE_v2.patch) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.2 Reporter: Lars Hofhansl Priority: Minor Attachments: HBASE-6580_v1.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-6580: - Attachment: HBASE-6580_v2.patch Added HConnection#getTable() New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.2 Reporter: Lars Hofhansl Priority: Minor Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-6580: - Affects Version/s: 0.92.2 0.94.2 Release Note: New HTableInterfaceFactory implementation using shared ExecutorService for all HTable instances managed by HTablePool Status: Patch Available (was: Open) This is something we need in production as well. Digging deeper I see the underlying HConnection is already shared in the current HTablePool impl. (i.e there is a single, private Configuration instance passed when HTablePool is initialised and used for all HTable instances built by pool). What is missing is a shared ExecutorService for all htable's so I called it SharedExecutorHTableFactory Patch attached (it's on hbase-trunk but I can easily port to 0.92 and 0.94) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.94.2, 0.92.2 Reporter: Lars Hofhansl Priority: Minor Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-6580: - Attachment: HBASE-6580_v1.patch New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Affects Versions: 0.92.2, 0.94.2 Reporter: Lars Hofhansl Priority: Minor Attachments: HBASE-6580_v1.patch Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Fix Version/s: (was: 0.94.2) (was: 0.96.0) Issue Type: Improvement (was: Bug) I likely won't get time to on this. New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Improvement Reporter: Lars Hofhansl Priority: Minor Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6580) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor
[ https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-6580: - Summary: New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor (was: New HTable pools, based on HBase(byte[], HConnection, ExecutorService) constructor) New HTable pool, based on HBase(byte[], HConnection, ExecutorService) constructor - Key: HBASE-6580 URL: https://issues.apache.org/jira/browse/HBASE-6580 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl Priority: Minor Fix For: 0.96.0, 0.94.2 Here I propose a very simple TablePool. It could be called LightHTablePool (or something - if you have a better name). Internally it would maintain an HConnection and an Executor service and each invocation of getTable(...) would create a new HTable and close() would just close it. In testing I find this more light weight than HTablePool and easier to monitor in terms of resources used. It would hardly be more than a few dozen lines of 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
